Le DNS de l’invité VirtualBox NAT casse quand l’hôte rejoint un VPN

Sur un hôte Windows, le nom interne de l’application se résout dès que le VPN se connecte, et dans un invité Ubuntu non. L’invité conserve ses propres paramètres de résolveur, et l’adaptateur NAT devant lui peut répondre aux requêtes DNS de deux manières différentes. Pointer l’invité vers un résolveur public fait recharger les sites tout en laissant les noms privés cassés. C’est pourquoi le chemin du résolveur est tracé avant toute modification.

Suivez une résolution à travers l’adaptateur NAT

Choisissez un nom interne pleinement qualifié et un nom public comme témoins. Tunnel monté, confirmez sur l’hôte que le nom interne se résout et que l’application derrière s’ouvre. Exécutez ensuite les deux mêmes requêtes dans l’invité et comparez les réponses, pas les outils.

Confirmez que l’adaptateur est bien un NAT simple avant d’aller plus loin. Un adaptateur pont, un réseau NAT nommé et un second client VPN dans l’invité ont chacun leur propre configuration et leur propre explication. Deviner à ce stade gaspille le reste de l’enquête.

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

La première commande affiche le mode de l’adaptateur et tout réseau NAT qui y est rattaché. Dans un invité Ubuntu, la deuxième liste les paramètres DNS par liaison, et la troisième ne révèle souvent qu’une adresse stub locale, ce qui signifie que le véritable upstream se trouve ailleurs.

Gardez la résolution et l’accessibilité séparées. Un invité qui reçoit la bonne adresse mais ne peut pas ouvrir de connexion a un problème de routage, de filtrage ou de droits du service, et d’autres changements DNS ne le toucheront jamais. Testez l’adresse séparément et notez laquelle des deux a échoué.

Le mode proxy et le mode résolveur de l’hôte sont des mécanismes différents

En mode proxy, le moteur NAT transmet les requêtes de l’invité à des serveurs DNS qu’il connaît déjà. En mode résolveur de l’hôte, il intercepte la requête et demande au système d’exploitation de l’hôte de résoudre le nom avec ce que l’hôte utilise à cet instant. Seul le second suit un client VPN qui réécrit la résolution de l’hôte quand le tunnel monte. C’est pourquoi les deux réglages produisent des réponses différentes sur la même machine.

Cette distinction, c’est tout le problème en une phrase. Donner à l’invité une liste d’adresses de serveurs n’est pas la même chose que demander à Windows de résoudre un nom via son résolveur configuré, et sur un VPN à DNS scindé les deux réponses diffèrent. L’option de l’adaptateur porte sur le mécanisme, pas sur l’autorisation.

Aucun des deux modes ne donne accès à quoi que ce soit. L’autorisation vit dans la politique VPN et dans le service, et une résolution qui fonctionne signifie seulement qu’un nom est devenu une adresse.

Basculez l’adaptateur, puis vérifiez ce que reçoit l’invité

Notez d’abord les paramètres réseau et DNS de la VM, puis éteignez la machine pour que ce soit la configuration persistante que vous modifiez. Pour une VM nommée work-ubuntu dont le premier adaptateur porte le NAT, l’option par adaptateur se règle depuis l’hôte, VM éteinte. Redémarrez-la ensuite et inspectez le résultat au lieu de vous fier au code de sortie.

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

Le dernier chiffre sélectionne le numéro d’adaptateur, ce n’est donc pas une valeur universelle ; un réglage pour l’adaptateur 2 porterait un 2 à cette position. Utilisez le binaire VBoxManage qui correspond à la version installée de VirtualBox, car un binaire plus ancien dans le PATH peut écrire des réglages que la version en cours ignore.

Activer plutôt l’option proxy choisit un autre mécanisme et ne vous donne pas le comportement du résolveur de l’hôte. Une fois l’invité démarré, vérifiez la configuration DNS qu’il détient réellement, car un résolveur épinglé ou un réglage de DNS chiffré dans l’invité maintient les applications sur un autre chemin, quel que soit ce que propose l’adaptateur.

Testez sur tout le cycle de vie du VPN, pas une seule fois

Répétez les deux résolutions dans l’invité, puis ouvrez la véritable application et laissez-la valider le nom d’hôte TLS. Un test de connexion en IP seule isole bien le DNS, mais ce n’est pas une vérification de certificat et il ne faut pas le présenter comme telle. Notez ensemble le nom, l’adresse et le résultat de l’application.

Pendant une fenêtre approuvée, déconnectez puis reconnectez le VPN de l’hôte et répétez le test. Le résultat devrait correspondre à la politique d’accès, et le fait que la résolution publique remarche ne dit rien sur la question de savoir si les requêtes privées sont restées sur le chemin prévu.

Quand le mode résolveur de l’hôte ne change rien, remettez la valeur enregistrée et conservez les observations. Un client VPN qui exclut le trafic de l’hyperviseur, un résolveur interne injoignable et un réglage d’invité épinglé demandent chacun une correction différente, et ponter l’adaptateur change la conception du réseau au lieu de réinitialiser le DNS.