ip netns exec et DNS : pourquoi les noms échouent dans l’espace de noms

Une commande atteint 10.8.0.5 à l’intérieur de l’espace de noms du VPN sans se plaindre, et la même commande échoue dès qu’elle utilise un nom d’hôte. L’espace de noms a ses propres interfaces, routes et sockets ; il n’a pas son propre fichier de résolution. À moins que quelque chose n’en place un là, le processus à l’intérieur lit le /etc/resolv.conf de l’hôte et interroge un serveur qui n’est peut-être pas joignable depuis cette pile réseau.

C’est un problème de sélection de fichier et non de routage, et c’est exactement pour cela que la destination numérique fonctionne encore.

Vérifiez la vue du résolveur que le processus reçoit réellement

Ne partez pas du principe que le shell que vous avez utilisé équivaut au processus que vous déboguez. Une application graphique, une unité systemd et un conteneur peuvent chacun entrer dans un contexte de montage ou de réseau différent. Lancez la requête par le même chemin de démarrage et imprimez le fichier du résolveur depuis l’intérieur.

Pour un espace de noms créé avec ip netns add, la vérification en lecture seule est courte :

ip netns exec vpn cat /etc/resolv.conf

Notez si le résultat nomme une adresse joignable, un stub de loopback ou un lien symbolique qui pointe vers un endroit dont la joignabilité diffère.

Ce que l’assistant exec monte réellement

L’outil ip-netns documente la configuration par espace de noms sous /etc/netns/NAME/. Lorsqu’il lance un processus, l’assistant crée un espace de noms de montage et monte ces fichiers par-dessus leurs chemins habituels, de sorte que le processus voit la copie propre à l’espace de noms. C’est une commodité de ce lanceur précis. Entrer dans un espace de noms réseau par un autre chemin, comme unshare ou un runtime de conteneurs, ne reproduit pas cela automatiquement.

Le résolveur de loopback est le piège ici : 127.0.0.53 désigne le loopback de l’espace de noms lui-même, pas le stub de l’hôte. Un stub qui n’écoute que dans l’espace de noms de l’hôte ne devient pas un service dans le nouveau.

Choisissez un résolveur que l’espace de noms peut joindre

Quel que soit le serveur que le fichier nomme, il a toujours besoin d’une route depuis cet espace de noms. Un résolveur public peut répondre aux noms publics et échouer malgré tout pour une zone interne, car le service privé n’est joignable que par le tunnel. Vérifiez la route en même temps que l’adresse, pas après que la requête a déjà échoué.

Les applications dotées de leur propre résolveur, comme celles qui utilisent DNS over HTTPS, peuvent ignorer complètement le fichier. Si l’outil a son propre réglage DNS, modifier resolv.conf n’y changera rien, et l’espace de noms n’a jamais été le problème.

Écrivez le fichier au bon endroit

Créez le fichier par espace de noms sous /etc/netns/NAME/resolv.conf et laissez le lanceur le présenter. Gardez-le minimal : un ou deux serveurs joignables et les domaines de recherche dont la tâche a besoin. Ne modifiez pas le fichier de résolveur généré de l’hôte pour corriger une vue destinée à un groupe de processus, car cela change toutes les applications de la machine. Si l’hôte utilise un gestionnaire de résolveur, configurez le chemin de l’espace de noms via ce gestionnaire plutôt que de lutter contre lui.

Consignez le contenu du fichier dans le runbook. Sinon, la personne suivante testera le résolveur de l’hôte, verra une réponse qui fonctionne et conclura que l’espace de noms est correct.

Retestez tout le chemin

Testez à l’intérieur de l’espace de noms avec une adresse numérique, un nom interne et un nom public. Cette séquence sépare la joignabilité de la résolution et sépare les zones internes des zones publiques. Recréez ensuite l’espace de noms et répétez, car un fichier qui n’existe que dans une instance en cours disparaît avec elle.

Confirmez que c’est le processus, et non le shell, qui reçoit le fichier. Une requête qui fonctionne depuis un shell interactif et échoue depuis un service est une constatation sur le contexte de montage, et elle mérite d’être écrite avant le prochain incident plutôt que redécouverte de zéro.