L’invité Hyper-V perd le DNS lorsque le VPN de l’hôte se connecte

L’invité allait bien ce matin. Puis l’hôte a démarré Cisco AnyConnect et la VM a perdu le DNS, l’approbation du domaine et le dossier partagé, sans que rien ne change à l’intérieur. Un tunnel d’hôte et un réseau d’invité sont des chemins distincts, et connecter l’un ne déplace pas l’autre. Travaillez de l’intérieur de l’invité vers l’extérieur, et notez ce que vous voyez avant de changer quoi que ce soit.

Ce que l’invité voit encore

Relevez l’adresse, la passerelle par défaut et le résolveur dans la VM, une fois avant que l’hôte se connecte et une fois après. Un invité qui a conservé son adresse et perdu seulement la résolution de noms a un problème de résolveur. Un invité qui n’a jamais eu de route a un problème de chemin, et les deux demandent un travail différent. Depuis l’hôte, vous ne pouvez pas les distinguer, c’est pourquoi la lecture doit venir de l’intérieur.

Ces trois relevés, pris deux fois, sont votre référence. Tout ce qui suit se mesure par rapport à eux.

Quelle sortie l’invité utilise

Hyper-V répond à cela avec deux commandes : Get-VMSwitch liste les commutateurs, et Get-VMNetworkAdapter -VMName TestVM montre celui auquel l’invité est rattaché. Le Default Switch est un réseau NAT géré par Windows ; un commutateur externe remet le trafic à un adaptateur physique ; un commutateur interne ne transporte rien tant que quelqu’un n’ajoute pas NAT ou un routeur. VirtualBox présente les trois mêmes idées sous les noms NAT, NAT Network et bridged.

Le mode décide si le tunnel de l’hôte peut avoir la moindre importance. Un invité NAT est traduit par WinNAT puis transféré par la pile de l’hôte, il suit donc la table de routage de l’hôte ; avec un client en tunnel complet, son trafic est le trafic qui entre dans l’adaptateur VPN, et il est abandonné lorsque le client bloque le sous-réseau local. Un invité ponté sur un commutateur externe n’atteint jamais le routage de l’hôte : ses trames quittent directement la carte réseau physique, il contourne donc à la fois le tunnel et la politique de réseau local du client.

Partager le tunnel de l’hôte avec Hyper-V

Si l’invité a besoin du tunnel et ne peut pas exécuter son propre client, Windows peut partager la connexion VPN. Ouvrez les propriétés de l’adaptateur VPN, allez dans Partage et autorisez d’autres utilisateurs réseau à s’y connecter. Dirigez la connexion réseau domestique vers l’adaptateur Hyper-V, vEthernet (Default Switch), puis testez une nouvelle requête depuis l’intérieur de l’invité.

Traitez ce montage comme une solution de laboratoire, car il se comporte comme telle. Il doit être réappliqué après une déconnexion, une reconnexion ou un redémarrage de l’hôte. Sur certaines versions de Windows 11, l’adaptateur manque totalement dans la liste déroulante, et cette voie est alors fermée.

La réinstallation de la fonctionnalité Hyper-V a sauvé quelques invités récalcitrants. Gardez cela pour la fin et notez d’abord l’état de l’invité.

Transfert de ports lorsque le sous-réseau est filtré

Un VPN d’hôte qui filtre le sous-réseau NAT de l’invité casse l’accès direct plutôt que la résolution de noms. La VM tourne, mais ssh [email protected] se bloque, alors que la traduction de l’hyperviseur fonctionne encore. Transférez les ports dont le travail a besoin et connectez-vous à l’adresse de l’hôte à la place. Les lignes Vagrantfile ci-dessous couvrent SSH et un service HTTPS ; les deux s’ajoutent avant le rechargement.

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

La résolution de noms est une décision distincte et mérite sa propre correction. Activez la fonction de résolveur de l’hôte pour cet adaptateur NAT, ou configurez le serveur DNS interne dans l’invité à la main. Pointer l’invité vers un résolveur public fait fonctionner la navigation et casse tous les noms internes, ce qui est pire que la panne parce que cela ressemble à un succès. Testez un nom que seul le résolveur interne connaît.

La vérification qui vous dit que cela a marché

Après l’un de ces changements, lancez une nouvelle requête depuis l’intérieur de l’invité avec le VPN de l’hôte connecté, pas avant. Revérifiez le partage après une reconnexion et après un redémarrage, car une correction qui ne survit qu’à l’un des deux n’est pas une correction. Confirmez que la liste des résolveurs de l’invité correspond au réseau que son trafic utilise réellement. Testez ensuite le transfert de ports depuis l’adresse de l’hôte, car le tester depuis l’invité ne prouve rien. Depuis l’intérieur de l’invité, deux vérifications PowerShell couvrent le résolveur et le port transféré :

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

Notez chaque changement de commutateur ou de pilote avec son étape d’annulation. Le guide Microsoft sur Hyper-V NAT explique ce qu’est réellement le Default Switch, et il vaut la peine d’être lu avant de créer un second réseau NAT qui entre en conflit avec lui.