Architecture WireGuard Mesh

Architecture

VPS OVH (10.0.0.1)      ←——tunnel——→    Marseille (10.0.0.2)
       |                                       |
       |                               tunnel direct P2P
       |                                       |
       └——tunnel——→    Albi (10.0.0.3) ←———————┘

Les besoins fonctionnelles & techniques

Cette architecture couvre des besoins bien définit qui pourrait résoudre des problématiques de sécurité entre plusieurs serveurs et services. 

Voici la liste des besoin couvert par cette architecture : 

• 1 - Se connecter au VPN des différents serveur
  • Hériter de l'adresse IP publique associé
  • Accéder au réseau local associé au serveur
  • Ne pas accéder au réseau local des AUTRES serveurs
  • Par exemple, je suis connecté au VPN du serveur de Marseille. J'ai alors l'adresse IP public de la box internet de MRS, j'ai accès à tous les appareils du réseau local de la box internet. Par contre je ne peux pas voir les autres appareils du réseau local de la box d'Albi.
• 2 - Faire communiquer les différents serveurs dans un tunnel privé et sécurisé
  • Chaque serveur est joignable via ce réseau privé
  • Les services Docker peuvent utiliser ce réseau privé pour communiquer avec les services des autres serveurs
    
  • Ce tunnel privé ne doit pas faire partie de la même configuration que le besoin 1
• 3 - Cette architecture doit fonctionner avec un seul et même Wireguard Docker par serveur

Les définitions

Mesh (ou réseau maillé) est une topologie réseau où chaque nœud est connecté directement à plusieurs autres, sans point central obligatoire. Dans notre cas, les 3 serveurs forment un mesh : OVH parle à Marseille, OVH parle à Albi, et Marseille parle directement à Albi. C'est l'opposé du hub-and-spoke où tout passe obligatoirement par le centre. L'avantage : si OVH tombe, Marseille et Albi continuent de se parler directement.

Exit Node est le nœud par lequel votre trafic internet "sort" vers le monde. Quand vous activez un profil exit node, vous dites à votre appareil "fais passer tout ton trafic internet par ce serveur". Le site que vous visitez voit alors l'IP publique du serveur exit node, pas votre vraie IP. C'est exactement le principe d'un VPN classique grand public (NordVPN, ExpressVPN…), sauf qu'ici vous gérez vous-même le serveur de sortie. Le terme vient de Tailscale qui l'a popularisé, mais le mécanisme (AllowedIPs = 0.0.0.0/0 + masquerading) existe depuis les débuts de WireGuard.

Plan d'adressage complet

Serveurs (peers fixes)

Clients (plages réservées)

Ordre de déploiement

Étape 1 — Générer toutes les clés

Sur chaque serveur, générer une paire de clés :

# Sur OVH
wg genkey | tee /etc/wireguard/privatekey-ovh | wg pubkey > /etc/wireguard/publickey-ovh

# Sur Marseille
wg genkey | tee /etc/wireguard/privatekey-mrs | wg pubkey > /etc/wireguard/publickey-mrs

# Sur Albi
wg genkey | tee /etc/wireguard/privatekey-albi | wg pubkey > /etc/wireguard/publickey-albi

# Pour chaque client
wg genkey | tee privatekey-client | wg pubkey > publickey-client

Étape 2 — Remplacer les placeholders

Dans tous les fichiers .conf, remplacer :

Étape 3 — Configuration des box internet

Box Marseille :

Box Albi :

Étape 4 — Démarrer dans l'ordre

# 1. Démarrer le hub OVH en premier
ssh ovh "cd /opt/wireguard && docker compose up -d"

# 2. Démarrer Marseille
ssh marseille "cd /opt/wireguard && docker compose up -d"

# 3. Démarrer Albi
ssh albi "cd /opt/wireguard && docker compose up -d"

Étape 5 — Configurer Portainer UI

Commandes utiles

Vérifier l'état des tunnels

# Sur n'importe quel serveur
docker exec wireguard-ovh wg show       # OVH
docker exec wireguard-mrs wg show       # Marseille
docker exec wireguard-albi wg show      # Albi

# Résultat attendu : chaque peer doit avoir un "latest handshake" récent
# et un compteur de bytes "received/sent" qui monte

Tester la connectivité mesh

# Depuis OVH, pinger Marseille et Albi
docker exec wireguard-ovh ping 10.0.0.2 -c 3
docker exec wireguard-ovh ping 10.0.0.3 -c 3

# Depuis Marseille, pinger Albi directement (tunnel P2P)
docker exec wireguard-mrs ping 10.0.0.3 -c 3

# Vérifier que le LAN de Marseille est accessible depuis Albi
docker exec wireguard-albi ping 192.168.1.1 -c 3

Vérifier que Portainer UI n'est pas exposé

# Cette commande doit échouer (connexion refusée) depuis internet
curl -v http://<IP_PUBLIQUE_OVH>:9000

# Ceci doit fonctionner uniquement avec le VPN actif
curl -v http://10.0.0.1:9000

Tester une sauvegarde rsync inter-serveurs

# Depuis Marseille vers Albi (tunnel P2P direct)
docker run --rm --network host \
  -v /data/backups:/source:ro \
  instrumentisto/rsync-ssh \
  rsync -avz --progress /source/ user@10.0.0.3:/backup/marseille/

# Vérifier que le trafic ne passe PAS par OVH :
# Sur OVH pendant le rsync : docker exec wireguard-ovh wg show
# → les bytes du peer MRS et Albi ne doivent PAS augmenter

Générer un QR code pour mobile (iOS/Android)

# Installer qrencode
apt install qrencode

# Générer le QR pour le profil OVH exit node
qrencode -t ansiutf8 < clients/ovh-exitnode.conf

# Scanner avec l'app WireGuard sur le téléphone

Redémarrer un tunnel après modification de config

docker compose restart wireguard
# OU
docker exec wireguard-ovh wg syncconf wg0 <(wg-quick strip wg0)

Structure des fichiers

wireguard-configs/
├── servers/
│   ├── ovh-wg0.conf           # Config WireGuard du VPS OVH
│   ├── marseille-wg0.conf     # Config WireGuard de Marseille
│   └── albi-wg0.conf          # Config WireGuard d'Albi
├── clients/
│   ├── ovh-exitnode.conf      # Client : IP publique = OVH
│   ├── mrs-exitnode.conf      # Client : IP publique = Marseille
│   ├── albi-exitnode.conf     # Client : IP publique = Albi
│   ├── mrs-lan.conf           # Client : accès LAN Marseille (split tunnel)
│   ├── albi-lan.conf          # Client : accès LAN Albi (split tunnel)
│   └── private-only.conf      # Client : réseau privé uniquement
├── docker-compose-all.yml     # docker-compose OVH + Marseille/Albi
└── README.md                  # Ce fichier

Sécurité — points d'attention