WireGuard dans un espace de noms réseau : pourquoi le socket est resté sur place

L’interface est bien listée dans l’espace de noms voulu, l’application y est rattachée, et pourtant aucun trafic de tunnel n’apparaît. C’est la signature d’un appareil WireGuard du noyau Linux créé dans un espace de noms puis déplacé dans un autre : l’interface a bougé, son socket UDP chiffré non. Les deux doivent être au bon endroit avant que le trafic interne n’ait d’importance. La vérification est rapide dès que l’on sait qu’il faut regarder deux contextes et non un seul.

Le symptôme : bon espace de noms, aucun paquet

À l’intérieur de l’espace de noms, le tunnel paraît sain. L’appareil existe, les adresses sont attribuées et la configuration du pair est présente. À l’extérieur, l’échange UDP attendu n’apparaît jamais sur l’interface que vous surveilliez, et l’autre côté signale qu’aucune poignée de main n’a eu lieu.

La raison est que les paquets internes de l’application atteignent l’appareil déplacé, et que l’appareil tente de les envoyer via un socket qui appartient à un autre contexte réseau. La route sous-jacente qu’il utilise, et chaque règle de pare-feu qui s’y applique, sont celles de l’espace de noms où l’appareil a été créé.

Ce n’est pas un défaut du déplacement, ni une mauvaise configuration du pair. C’est le comportement de l’implémentation du noyau, et la documentation des espaces de noms de WireGuard décrit directement la règle de création.

Pourquoi le socket a un lieu de naissance

Un appareil WireGuard possède un socket UDP pour son transport chiffré, et ce socket est ouvert dans l’espace de noms où l’appareil est créé. Déplacer l’interface avec une commande de liaison déplace l’appareil visible mais laisse le transport là où il a commencé. Les deux objets ont alors des propriétaires différents.

La conséquence est facile à manquer parce que les deux moitiés s’inspectent à des endroits différents. La route interne est décidée dans l’espace de noms où l’application s’exécute, et la route externe est décidée là où vit le socket. Vérifier une seule des deux produit une conclusion assurée mais fausse. Vérifier les deux termine généralement l’enquête en une seule passe.

Créez-le là où vous voulez le socket

La solution est de créer l’appareil à l’intérieur de l’espace de noms cible plutôt que de le créer à l’extérieur puis de le déplacer. En supposant qu’un espace de noms approuvé existe déjà et que le nom soit libre :

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

Désormais, l’interface et son socket appartiennent à ce contexte, donc la route sous-jacente et les règles de filtrage applicables sont celles configurées là. Si la conception exige le côté clair ailleurs, placez d’abord l’interface sous-jacente dans l’espace de noms, puis créez le tunnel. L’ordre fait partie de la conception, ce n’est pas un détail d’implémentation.

Considérez-les comme des commandes d’administration réseau, non comme une recette. Elles créent un appareil et affichent l’état ; les clés, les pairs, les adresses et les routes doivent toujours provenir d’une configuration approuvée, et une interface de production existante ne devrait jamais être substituée dans un exemple.

Lisez les deux côtés du chemin

Une fois l’appareil au bon endroit, vérifiez les deux décisions séparément. Commencez par la résolution interne depuis le contexte de l’application, puis vérifiez le chemin externe depuis le contexte qui possède le socket :

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

Si la résolution interne passe par le tunnel et que la capture externe montre l’échange chiffré, les deux moitiés concordent. Si la capture est vide, le socket est encore ailleurs, ou la route sous-jacente de son espace de noms n’atteint pas le point de terminaison.

Une vérification de plus appartient au dossier : comment l’appareil est créé après un redémarrage. Un gestionnaire qui recrée l’interface avec un autre contexte de création change le lieu de naissance du socket. Un déplacement manuel qui a fonctionné une fois ne prouve rien sur le chemin géré.