Partager le réseau d’un conteneur VPN : ce qui arrive au DNS

Partager l’espace de noms réseau d’un conteneur VPN donne à votre application les interfaces et les routes du tunnel. Il ne lui donne pas le résolveur du tunnel, ni une copie fusionnée de quoi que ce soit d’autre sur l’hôte. Cet écart produit une panne très précise : les noms publics se résolvent, les noms internes non, et l’application qui échoue semble utiliser le mauvais serveur DNS, parce que c’est le cas. La réparation est généralement plus petite que ne le suggère le diagnostic.

Étape 1 : Testez depuis l’application, pas depuis l’hôte

Exécutez la recherche dans le conteneur qui a le problème, pas sur l’hôte et pas dans un navigateur. docker exec app-container getent hosts db.internal répond à la seule question qui compte : ce que renvoie le résolveur de ce processus.

Si l’hôte résout le nom et pas le conteneur, vous avez trouvé la panne. Tout le reste consiste à choisir une manière prise en charge de la corriger.

Étape 2 : Lisez le modèle pris en charge par le runtime

La documentation réseau de Docker consigne des restrictions sur les options DNS pour les conteneurs qui partagent le mode réseau d’un autre conteneur. Dans Compose, network_mode: service:vpn lie l’application à l’espace de noms du conteneur VPN, et par service dns les réglages ne se comportent pas comme pour un service ordinaire. La résolution que vous obtenez est celle que possède l’espace de noms partagé.

Les réseaux pont définis par l’utilisateur utilisent eux aussi le DNS intégré de Docker différemment du pont par défaut. C’est pourquoi une dns clause copiée d’un exemple de pont qui fonctionne peut ne rien faire du tout dans une pile partagée. Vérifiez la configuration avant de copier la clause.

Une adresse de bouclage désigne toujours le contexte réseau concerné. Dans un espace de noms partagé, 127.0.0.1 n’est pas le résolveur de l’hôte.

Étape 3 : Suivez la requête jusqu’à son destinataire

Lisez la configuration du résolveur de l’application, puis tout DNS chiffré propre à l’application qu’elle embarque, car une application qui exécute son propre résolveur ignore le fichier que vous avez modifié. Vérifiez ensuite si le résolveur choisi est joignable sous les routes et la politique de pare-feu du VPN. Une adresse de résolveur de l’autre côté du tunnel est inutile si l’espace de noms n’a pas de route vers elle. Confirmez le destinataire avant de modifier le moindre fichier.

Une page de vérification d’IP dans un navigateur ne peut pas vous dire où sont allées les requêtes de noms. Elle vous dit où est allée une connexion HTTP.

Étape 4 : Corrigez les deux classes de panne différemment

Si les noms de service échouent alors que les noms publics fonctionnent, le problème vient de la découverte de services à l’intérieur du réseau de conteneurs, pas de la liste des résolveurs publics. Changer chaque adresse DNS publique ne créera pas d’enregistrements que le mécanisme de découverte du réseau n’a jamais été prié de créer.

Si les deux classes échouent, commencez par la joignabilité du résolveur. Si une seule échoue, commencez par le mécanisme de découverte. Les deux ont des propriétaires différents, c’est pourquoi une réparation ne couvre jamais les deux.

Étape 5 : Retestez après recréation

Modifiez la configuration via le mécanisme pris en charge du runtime, puis recréez les conteneurs au lieu de modifier des fichiers dans un conteneur en cours d’exécution. Testez un nouveau nom privé, un nouveau nom public et la requête applicative qui suit la recherche. Une modification dans /etc/resolv.conf à l’intérieur d’un conteneur disparaît à la recréation et vous convaincra que la réparation a fonctionné alors qu’elle ne l’a pas fait.

Notez le propriétaire du résolveur et l’espace de noms attendu à côté de la définition du réseau partagé. La personne suivante aura besoin des deux.