Relie deux LAN avec WireGuard

L’idée reçue

« Un VPN crée automatiquement les routes dont l’entreprise a besoin. »

WireGuard chiffre et associe des préfixes à des peers. Le système conserve toutefois sa propre table de routage. Un tunnel peut donc avoir un handshake valide et ne transporter aucun LAN si la route ou AllowedIPs est incorrect.

Le laboratoire construit deux sites reliés par un réseau de transport direct :

10.60.10.10 ─ site A ─ 192.0.2.1 ===== 192.0.2.2 ─ site B ─ 10.60.20.10
                       UDP 51820
                   wg0 10.255.0.1/30 ↔ 10.255.0.2/30

01Créer l’underlay et le tunnel

chmod +x module4b-wireguard-lab.sh
sudo ./module4b-wireguard-lab.sh site

Le script crée deux routeurs et deux postes. Les interfaces wan0 constituent l’underlay. Les interfaces wg0 forment l’overlay chiffré.

Underlay192.0.2.0/30

Transporte les datagrammes UDP WireGuard.

Overlay10.255.0.0/30

Identifie les deux extrémités du tunnel.

LAN privés10.60.10.0/24 ↔ 10.60.20.0/24

Trafic métier encapsulé dans le tunnel.

02Inspecter les clés sans exposer les secrets

sudo ls -l /tmp/soria-wireguard-lab
sudo cat /tmp/soria-wireguard-lab/site-a.pub
sudo cat /tmp/soria-wireguard-lab/site-b.pub

Le répertoire et les clés privées sont créés avec des permissions restrictives. Une clé publique peut être échangée ; une clé privée ne doit pas apparaître dans un ticket, un dépôt Git, une capture d’écran ou un journal de CI.

Comprends l’identité d’un peer

WireGuard n’utilise ni mot de passe ni certificat X.509 dans ce laboratoire. Chaque peer est identifié par sa clé publique. La possession de la clé privée permet de prouver cette identité et de déchiffrer le trafic destiné au peer.

03Lire la configuration réelle

sudo ip netns exec wg-a-rtr wg show
sudo ip -n wg-a-rtr route
sudo ip -n wg-b-rtr route

Sur le site A, le peer du site B annonce notamment :

endpoint: 192.0.2.2:51820
allowed ips: 10.255.0.2/32, 10.60.20.0/24

Le script ajoute également une route Linux :

10.60.20.0/24 dev wg0

AllowedIPs indique quel peer peut recevoir ou émettre pour un préfixe. La route indique à Linux que les paquets destinés à ce préfixe doivent entrer dans wg0.

04Déclencher le handshake

sudo ip netns exec wg-a-host ping -c 3 10.60.20.10
sudo ip netns exec wg-a-rtr wg show

Après le premier trafic, observe :

latest handshake: ... seconds ago
transfer: ... received, ... sent

WireGuard reste silencieux lorsqu’il n’a rien à transmettre. Le handshake apparaît donc au premier paquet utile.

05Voir l’enveloppe chiffrée

Dans un terminal :

sudo ip netns exec wg-a-rtr tcpdump -ni wan0 udp port 51820

Dans un autre :

sudo ip netns exec wg-a-host ping -c 3 10.60.20.10

Puis capture le trafic décapsulé :

sudo ip netns exec wg-a-rtr tcpdump -ni wg0 icmp

Sur wan0, tu vois seulement UDP entre 192.0.2.1 et 192.0.2.2. Sur wg0, tu vois l’ICMP privé entre les deux LAN. L’underlay transporte l’overlay sans connaître son contenu.

Panne volontaire

Retire la route sans casser le handshake

supprime la route vers le LAN du site B ;
vérifie que wg show conserve le dernier handshake ;
relance le ping et observe la décision de route ;
rétablis la route et valide.

sudo ip -n wg-a-rtr route del 10.60.20.0/24
sudo ip netns exec wg-a-host ping -c 2 10.60.20.10
sudo ip -n wg-a-rtr route add 10.60.20.0/24 dev wg0

06Nettoyer

sudo ./module4b-wireguard-lab.sh cleanup

✓Ce que tu retiens

Un VPN site-à-site exige quatre éléments cohérents : un underlay joignable, des clés correctes, des AllowedIPs non ambigus et des routes vers les LAN distants. Le handshake confirme le peer ; il ne valide pas à lui seul tout le chemin réseau.