Le DNS de l'invité VirtualBox casse après que l'hôte rejoint un VPN

Une application interne se résout sur l'hôte Windows à l'instant où le VPN se connecte, et l'invité Ubuntu derrière le NAT de VirtualBox ne la trouve toujours pas. L'invité a son propre résolveur, et l'adaptateur NAT peut gérer le DNS de plus d'une manière. Remplacer le résolveur de l'invité par un serveur public fait fonctionner les sites ordinaires et échouer les noms privés, ce qui déplace le problème au lieu de le résoudre. Faites les quatre vérifications dans l'ordre et arrêtez-vous à la première qui ne tient pas.

Confirmez le mode d'adaptateur que vous dépannez

Seul un adaptateur en mode NAT simple se comporte comme cet article le décrit. Un adaptateur pont se trouve sur le réseau physique avec sa propre identité, un réseau NAT est un commutateur virtuel nommé avec ses propres réglages DHCP et DNS, et un client VPN dans l'invité ajoute un second résolveur à part entière. Confirmez le mode avant de lire la suite, car la réparation diffère dans chacun de ces cas.

Une machine virtuelle peut porter deux adaptateurs dans des modes différents, et celui qui est affecté n'est pas toujours le premier.

Confirmez aussi que l'hôte résout le nom tout court. Ouvrez la même application sur l'hôte avec le tunnel monté, en utilisant le même nom pleinement qualifié que l'invité utilisera. Si l'hôte échoue aussi, l'invité n'est pas en cause et aucun changement de réseau virtuel n'y remédiera.

Suivez un nom à travers le résolveur de l'invité

Choisissez un nom interne et un nom public de contrôle, puis testez les deux aux deux endroits. Un nom public qui se résout alors que le privé ne le fait pas localise la panne sur le chemin privé et non sur la résolution de noms en général. Tester seulement le nom privé vous laisse incapable de distinguer un résolveur cassé d'une route cassée.

Dans l'invité, regardez ce pour quoi le résolveur est réellement configuré. Sur un invité Ubuntu avec systemd-resolved, l'état par lien montre les serveurs qui sont arrivés, et le fichier resolv.conf peut ne contenir qu'une adresse stub, ce qui est correct et non suspect. Un fichier édité à la main ou un client DNS chiffré séparé peut envoyer les requêtes tout ailleurs. Notez ce que vous trouvez avant de changer quoi que ce soit.

resolvectl status
resolvectl query app.internal.example

Séparez ici la résolution de l'accessibilité. Une adresse qui arrive pendant que le service reste inaccessible est une question de routage ou de politique, pas de DNS.

Essayez le mode résolveur de l'hôte sur cet adaptateur

Les options DNS de NAT de VirtualBox décrivent des mécanismes différents, et la différence compte dès que le résolveur propre de l'hôte change avec le tunnel. Le proxy DNS transmet les requêtes de l'invité aux serveurs qu'on lui a fournis. Le mode résolveur de l'hôte intercepte les requêtes et appelle l'API DNS de l'hôte, et c'est le mode qui suit un résolveur Windows reconfiguré par un client VPN.

Activez le mauvais mécanisme et la commande réussit quand même alors que le comportement ne change pas, ce qui est une façon déroutante de perdre un après-midi.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Notez les réglages actuels de la machine virtuelle, éteignez-la et ciblez l'adaptateur que vous avez confirmé plus tôt. Le dernier chiffre de l'option est un numéro d'adaptateur et non une constante, donc l'appliquer à une machine dont l'adaptateur affecté est le second est une opération silencieuse sans effet. Démarrez l'invité et vérifiez la configuration de résolveur qu'il a réellement reçue, car un réglage manuel dans l'invité prime sur tout ce que la couche NAT propose. Rappelez-vous que le mode résolveur de l'hôte suppose aussi que le chemin DNS propre de l'hôte est celui que vous vouliez partager.

Refaites les mêmes tests lors d'une reconnexion VPN

Répétez les deux requêtes dans l'invité, puis ouvrez la vraie application et laissez-la valider le certificat elle-même. Un test uniquement d'adresse est utile pour isoler la résolution de noms et n'équivaut pas à une session TLS fonctionnelle, donc ne vous arrêtez pas à un ping. Puis, dans une fenêtre approuvée, déconnectez et reconnectez le tunnel de l'hôte et répétez une fois de plus. Un comportement qui ne tient qu'à la première connexion après le démarrage est un problème de cycle de vie à signaler, pas un mystère DNS à traquer avec un autre résolveur.

Que la résolution publique fonctionne ne prouve pas que les requêtes privées soient restées sur le chemin qu'exige votre politique.

Quand le mode résolveur de l'hôte ne change rien, remettez la configuration notée et gardez les quatre observations : ce que l'hôte a renvoyé, ce que l'invité a renvoyé, le mode de l'adaptateur et l'état du résolveur. Un serveur interne inaccessible, un filtre qui exclut le trafic de l'hyperviseur et un contournement côté invité demandent chacun une correction différente. Convertir l'adaptateur en pont change la conception du réseau et n'est pas une réinitialisation du DNS.