La poignée de main WireGuard fonctionne, mais le sous-réseau du bureau ne répond pas

La poignée de main se termine, wg show signale un transfert récent, et l'adresse tunnel du serveur répond au ping. Un hôte du LAN du serveur, non. Trois conditions doivent être réunies en même temps : le client doit router le préfixe du LAN dans le tunnel, le serveur doit transférer les paquets, et la réponse a besoin d'un chemin de retour. Quand l'une des trois manque, le symptôme est identique.

AllowedIPs est à la fois une liste d'accès et une table de routage

Sur le client, la liste AllowedIPs décide à la fois de ce qui peut être envoyé à ce pair et des routes que WireGuard installe. Une entrée de pair qui ne liste que l'adresse tunnel du serveur installe une seule route d'hôte, si bien que les destinations du LAN n'entrent jamais dans le tunnel. Ajouter le préfixe du LAN est la première chose à vérifier, et c'est aussi la modification qui manque le plus souvent après une configuration copiée. Un pair élargi à une route par défaut est une autre conception, et il déplacera aussi le trafic internet du client.

Gardez la route d'hôte et le préfixe du LAN comme des entrées séparées. Si le bureau a deux sous-réseaux, les deux appartiennent à la liste, et le second préfixe manquant produit une panne qui semble sélective plutôt que totale.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Le transfert et la traduction appartiennent au serveur

Le serveur a besoin du transfert IP activé, d'une règle de transfert qui accepte le trafic venant du tunnel, et d'une règle de traduction vers son interface LAN. C'est la traduction qui fait fonctionner la conception sans toucher à chaque hôte du réseau du bureau. Les réponses reviennent alors au serveur plutôt qu'à une adresse dont le LAN n'a jamais entendu parler. Sans elle, chaque hôte a besoin d'une route pour le sous-réseau du tunnel et d'une règle de pare-feu qui l'autorise, ce qui est rarement acceptable sur un réseau géré par quelqu'un d'autre.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Les règles ajoutées à la main disparaissent au redémarrage, alors liez-les à l'interface avec les commandes de crochet de la configuration du serveur. Un ensemble de règles qui survit à son interface, c'est ainsi qu'une machine finit par traduire le trafic d'un tunnel qui n'existe plus.

Quand le LAN a déménagé et pas la règle

Le remplacement d'un routeur qui renumérote le sous-réseau du bureau est la version classique de cette panne. Le tunnel reste actif, la poignée de main reste fraîche, et rien derrière le serveur ne répond, parce que la règle de traduction nomme encore l'ancienne adresse. Les scripts d'installation intègrent souvent l'adresse LAN du serveur dans une règle POSTROUTING, et après une renumérotation cette adresse n'existe sur aucune interface. Les paquets sont alors réécrits vers une destination qui ne peut pas répondre.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Comparez les deux sorties. Une cible de traduction qui n'apparaît pas dans la liste des interfaces est le bogue, et le corriger est une modification d'une ligne une fois qu'on l'a vue. La règle peut vivre dans une unité générée plutôt que dans la configuration WireGuard, alors rechargez cette unité après édition et confirmez que le prochain démarrage ne réécrit pas votre changement.

Deux sites derrière NAT ont besoin d'un lieu de rencontre

Quand aucun des deux côtés n'accepte de connexions entrantes, la réponse pratique est un petit hôte avec une adresse publique et deux interfaces WireGuard. Chaque site se connecte vers l'extérieur, l'hôte central liste le LAN de chaque pair dans son propre AllowedIPs, et le transfert achemine les paquets entre les deux tunnels. Rien dans le pare-feu de l'un ou l'autre site n'a besoin de changer, et c'est pourquoi cette conception se répand facilement.

Le routage entre les sites conserve les adresses source d'origine et garde donc une journalisation par hôte significative. La traduction sur l'hôte central est plus simple quand les deux LAN se chevauchent, au prix de la perte de l'identité de la source dans les journaux. Décidez quelle propriété compte avant de choisir.

Séparez les couches avec quatre vérifications

Faites une vérification par couche plutôt que de changer trois choses en espérant. La première montre l'âge de la poignée de main et les compteurs de chaque pair. La deuxième montre si le client route réellement cette destination dans le tunnel. La troisième et la quatrième vous disent si la requête est arrivée et si une politique l'a rejetée après son arrivée.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Une requête qui arrive et ne suscite aucune réponse pointe vers le chemin de réponse ou vers l'hôte du LAN. Une requête qui n'arrive jamais pointe vers AllowedIPs ou vers la route du client. Ces deux résultats demandent des corrections différentes, et la capture est ce qui les distingue.