Nutzt eine Hyper-V-VM das VPN des Hosts? Das hängt vom Switch ab

Installieren Sie einen VPN-Client auf dem Hyper-V-Host, öffnen Sie dort einen Browser, und die Ausgangsadresse ändert sich; öffnen Sie dieselbe Seite in der VM, und sie zeigt vielleicht die alte Adresse oder gar nichts. Der übliche Schluss ist, dass die VM defekt ist oder Split-Tunneling aktiviert werden muss. Nichts davon folgt. Ein VPN-Client ist keine Eigenschaft der Maschine; er ist eine Menge von Routen, ein virtueller Adapter und oft ein Filter, der an bestimmte Schnittstellen gebunden ist. Ob Gastverkehr dieser Maschinerie je begegnet, hängt vom virtuellen Switch ab, den der Gast verwendet.

Der Mythos, klar gesagt

Der Glaube lautet, ein auf dem Host installiertes VPN schütze die ganze Maschine einschließlich der VMs, weil eine VM nur ein Prozess auf dieser Maschine sei. Es ist ein bequemer Glaube, weil Antivirus und Host-Firewalls sich gewöhnlich so verhalten. Netzwerkpfade nicht.

Ein Gast-Frame wird nur dann vom VPN-Stack des Hosts berührt, wenn der Host ihn routet oder filtert. Schreiben Sie diesen Satz auf einen Haftzettel, denn jeder Fall unten ist eine Variante davon.

Drei Switch-Typen, drei Wege

Ein externer Switch bindet einen virtuellen Adapter an eine physische Netzwerkkarte, und der Gast sendet Frames über diese Bindung mit seiner eigenen MAC-Adresse. Der Gast wird zu einem Gleichberechtigten im physischen Netz, mit eigenem DHCP-Lease, Gateway und DNS-Servern. Die VPN-Standardroute des Hosts lebt im Host-Stack und bewegt diese Frames nicht, weil sie gebrückt und nicht durch den Host geroutet werden. Deshalb ist ein externer Switch über einem Wi-Fi-Adapter eine schlechte Idee: Die meisten WLAN-Treiber übertragen keine Frames für eine zweite MAC-Adresse.

Ein interner Switch verbindet Gäste mit einem virtuellen Adapter des Hosts. Für sich genommen bietet er keinen Internetausgang; ein NAT-Objekt auf dem Host übernimmt die Übersetzung, wie im Hyper-V-NAT-Leitfaden beschrieben. Jetzt gelangen die Pakete des Gastes tatsächlich in Routing und NAT-Pfad des Hosts, also zählen die Routen und Filter des VPN-Clients wieder. Das ist die Anordnung, in der die VM dem Host-VPN wirklich folgt und in der ein Kill Switch den Gast vollständig abschneiden kann.

Ein privater Switch hat keinen Host-Adapter und keinen Uplink. Gäste sprechen miteinander und mit nichts anderem, wenn also eine VM an einem privaten Switch kein Internet hat, ist der fehlende Router die Ursache und das VPN irrelevant.

Der Standard-Switch ist eine eigene Anordnung

Windows liefert einen Standard-Switch, der einen internen Switch mit NAT und einem DNS-Proxy kombiniert. Sein Subnetz wählt der Host, es kann sich nach Neustarts ändern und ist nicht dasselbe Objekt wie ein NAT-Netzwerk, das Sie selbst anlegen. Ihn neu aufzubauen, als wäre er ein Labornetz, ist der Weg, auf dem Leute mit zwei NATs und einem Gast ohne Route enden.

Wenn die VM am Standard-Switch hängt, lesen Sie die Adresse, die der Gast erhalten hat, und vergleichen Sie sie mit der NAT-Tabelle des Hosts, bevor Sie den VPN-Client anfassen. Eine Abweichung zwischen Gast-Gateway und NAT-Präfix erklärt mehr Fehlschläge als jede Client-Einstellung.

Vier Fakten, die die Frage klären

Sammeln Sie dies, bevor Sie etwas ändern: den Switch-Typ und seinen Uplink, den an die VM angebundenen Adapter, die eigene Adresse, das Gateway und DNS des Gastes sowie den NAT- und Standardrouten-Zustand des Hosts. Die Nur-Lese-Befehle sind Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, und Get-NetRoute -DestinationPrefix 0.0.0.0/0; und im Gast liefert ipconfig /all den Rest.

Entscheiden Sie dann, was der Gast tun soll. Wenn er außerhalb des VPN bleiben soll, holen Sie die unterstützte Ausnahme des Anbieters für genau diesen Pfad ein, denn der Ausschluss einer Host-Anwendung befreit keinen weitergeleiteten VM-Verkehr. Wenn er das VPN nutzen soll, bestätigen Sie die dokumentierte Behandlung von VM-Verkehr durch den Client, statt anzunehmen, ein Test im Host-Browser decke das ab.

Ein Test im Gast ist der einzige Beweis, der zählt. Prüfen Sie die Ausgangsadresse aus dem Gast, lösen Sie einen internen Namen auf, verbinden Sie das VPN neu und wiederholen Sie das. Das Browser-Ergebnis des Hosts ersetzt nichts davon.

Was der Mythos kostet

Leute schalten den Kill Switch ab, fügen statische Routen hinzu oder löschen und erzeugen Switches neu, nur damit ein Test besteht. Jede Abkürzung ändert den Fehlermodus: Der Gast erreicht das Internet über einen Pfad, den niemand vorgesehen hat, oder der Host verliert die Verbindung, wenn ein externer Switch seine physische Karte neu bindet.

Das erneute Binden eines externen Switches unterbricht den eigenen Zugang des Hosts, also halten Sie einen Out-of-Band-Pfad offen und vermeiden Sie es, Switches zu löschen, während Sie noch diagnostizieren. Das richtige Ergebnis ist der beabsichtigte Gastpfad, einschließlich wie er sich neu verbindet und wie er scheitert, kein grüner Haken nach einem Seitenaufruf.

Die dauerhafte Antwort ist eine Zeile pro VM im Inventar: welchen Switch sie nutzt und welche Komponente ihr Gateway liefert. Ist das aufgeschrieben, ist die nächste VPN-Änderung ein Nachschlagen statt eines Nachmittags voller Vermutungen.