Une machine virtuelle Hyper-V utilise-t-elle le VPN de l'hôte ? Cela dépend du commutateur

Installez un client VPN sur l'hôte Hyper-V, ouvrez-y un navigateur, et l'adresse de sortie change ; ouvrez la même page dans la machine virtuelle et elle peut afficher l'ancienne adresse, ou rien du tout. La conclusion habituelle est que la machine virtuelle est cassée, ou qu'il faut activer le tunnel divisé. Ni l'une ni l'autre ne s'ensuit. Un client VPN n'est pas une propriété de la machine ; c'est un ensemble de routes, un adaptateur virtuel et souvent un filtre lié à des interfaces précises. Que le trafic des invités rencontre un jour ce mécanisme dépend du commutateur virtuel utilisé par l'invité.

Le mythe, dit simplement

La croyance est qu'un VPN installé sur l'hôte protège toute la machine, machines virtuelles comprises, parce qu'une machine virtuelle n'est qu'un processus exécuté sur cette machine. C'est une croyance confortable, car l'antivirus et les pare-feu de l'hôte se comportent généralement ainsi. Les chemins réseau, non.

La trame d'un invité n'est touchée par la pile VPN de l'hôte que si l'hôte la route ou la filtre. Copiez cette phrase sur un papier collant, car chaque cas ci-dessous en est une variante.

Trois types de commutateur, trois chemins

Un commutateur externe lie un adaptateur virtuel à une carte réseau physique, et l'invité envoie des trames par cette liaison avec sa propre adresse MAC. L'invité devient un pair sur le réseau physique, avec son propre bail DHCP, sa passerelle et ses serveurs DNS. La route par défaut du VPN de l'hôte vit dans la pile de l'hôte et ne déplace pas ces trames, car elles sont pontées plutôt que routées par l'hôte. C'est aussi pourquoi un commutateur externe sur un adaptateur Wi-Fi est une mauvaise idée : la plupart des pilotes sans fil ne transportent pas de trames pour une seconde adresse MAC.

Un commutateur interne relie les invités à un adaptateur virtuel de l'hôte. À lui seul, il n'offre aucune sortie internet ; un objet NAT sur l'hôte assure la traduction, comme décrit dans le guide NAT de Hyper-V. Désormais, les paquets de l'invité entrent bien dans le routage et le chemin NAT de l'hôte, donc les routes et les filtres du client VPN comptent de nouveau. C'est la disposition où la machine virtuelle suit réellement le VPN de l'hôte, et où un kill switch peut couper complètement l'invité.

Un commutateur privé n'a ni adaptateur d'hôte ni liaison montante. Les invités se parlent entre eux et à rien d'autre, donc si une machine virtuelle sur un commutateur privé n'a pas internet, le routeur manquant en est la cause et le VPN n'y est pour rien.

Le commutateur par défaut est une disposition à part

Windows fournit un commutateur par défaut qui combine un commutateur interne avec NAT et un proxy DNS. Son sous-réseau est choisi par l'hôte, peut changer après un redémarrage et n'est pas le même objet qu'un réseau NAT que vous créez vous-même. Le reconstruire comme s'il s'agissait d'un réseau de laboratoire est la façon dont les gens finissent avec deux NAT et un invité toujours sans route.

Si la machine virtuelle est sur le commutateur par défaut, lisez l'adresse reçue par l'invité et comparez-la à la table NAT de l'hôte avant de toucher au client VPN. Un écart entre la passerelle de l'invité et le préfixe NAT explique plus de pannes que n'importe quel réglage du client.

Quatre faits qui tranchent la question

Rassemblez ceci avant de changer quoi que ce soit : le type de commutateur et sa liaison montante, l'adaptateur relié à la machine virtuelle, l'adresse, la passerelle et le DNS de l'invité lui-même, ainsi que l'état NAT et de route par défaut de l'hôte. Les commandes en lecture seule sont Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, et Get-NetRoute -DestinationPrefix 0.0.0.0/0 ; et dans l'invité, ipconfig /all donne le reste.

Décidez ensuite ce que l'invité est censé faire. S'il doit rester hors du VPN, obtenez l'exception prise en charge par le fournisseur pour ce chemin précis, car exclure un exécutable de l'hôte n'exempte pas le trafic de machine virtuelle transmis. S'il doit utiliser le VPN, confirmez le traitement documenté du trafic des machines virtuelles par le client au lieu de supposer qu'un test dans le navigateur de l'hôte le couvre.

Un test à l'intérieur de l'invité est la seule preuve qui compte. Vérifiez l'adresse de sortie depuis l'invité, résolvez un nom interne, reconnectez le VPN et répétez. Le résultat du navigateur de l'hôte ne remplace rien de tout cela.

Ce que coûte le mythe

Les gens désactivent le kill switch, ajoutent des routes statiques ou suppriment et recréent des commutateurs juste pour faire passer un test. Chaque raccourci change le mode de défaillance : l'invité peut atteindre internet par un chemin que personne n'avait prévu, ou l'hôte peut perdre la connectivité quand un commutateur externe relie à nouveau sa carte physique.

Relier à nouveau un commutateur externe interrompt l'accès propre de l'hôte, donc gardez un chemin hors bande ouvert et évitez de supprimer des commutateurs pendant que vous diagnostiquez encore. Le résultat correct est le chemin voulu de l'invité, y compris comment il se reconnecte et comment il échoue, pas une coche verte après un chargement de page.

La réponse durable est une ligne par machine virtuelle dans l'inventaire : quel commutateur elle utilise et quel composant fournit sa passerelle. Une fois cela écrit, le prochain changement de VPN est une consultation au lieu d'un après-midi de suppositions.