Hyper-V-Gast verliert DNS, wenn sich das Host-VPN verbindet

Dem Gast ging es heute Morgen gut. Dann startete der Host Cisco AnyConnect, und die VM verlor DNS, das Domänenvertrauen und den freigegebenen Ordner, ohne dass sich darin etwas geändert hätte. Host-Tunnel und Gastnetz sind getrennte Wege, und das Verbinden des einen verschiebt den anderen nicht. Arbeiten Sie vom Gast nach außen und notieren Sie, was Sie sehen, bevor Sie etwas ändern.

Was der Gast noch sieht

Erfassen Sie Adresse, Standardgateway und Resolver in der VM, einmal bevor der Host sich verbindet und einmal danach. Ein Gast, der seine Adresse behielt und nur die Namensauflösung verlor, hat ein Resolver-Problem. Ein Gast, der nie eine Route hatte, hat ein Pfadproblem, und beide erfordern unterschiedliche Arbeit. Vom Host aus können Sie sie nicht unterscheiden, deshalb muss die Messung von innen kommen.

Diese drei Messungen, zweimal genommen, sind Ihre Basislinie. Alles Weitere wird daran gemessen.

Welchen Ausgang der Gast benutzt

Hyper-V beantwortet das mit zwei Befehlen: Get-VMSwitch listet die Switches auf, und Get-VMNetworkAdapter -VMName TestVM zeigt den, an den der Gast angebunden ist. Der Default Switch ist ein NAT-Netzwerk, das Windows verwaltet; ein externer Switch übergibt den Verkehr an einen physischen Adapter; ein interner Switch trägt nichts, bis jemand NAT oder einen Router hinzufügt. VirtualBox stellt dieselben drei Ideen als NAT, NAT Network und bridged dar.

Der Modus entscheidet, ob der Host-Tunnel überhaupt eine Rolle spielen kann. Ein NAT-Gast wird von WinNAT übersetzt und dann vom Host-Stack weitergeleitet, folgt also der Routentabelle des Hosts; mit einem Full-Tunnel-Client ist sein Verkehr der Verkehr, der in den VPN-Adapter eintritt, und er wird verworfen, wenn der Client das lokale Subnetz blockiert. Ein gebrückter Gast an einem externen Switch erreicht das Host-Routing nie: Seine Frames verlassen die physische NIC direkt, sodass er sowohl den Tunnel als auch die Local-LAN-Richtlinie des Clients umgeht.

Den Host-Tunnel mit Hyper-V teilen

Wenn der Gast den Tunnel braucht und keinen eigenen Client ausführen kann, kann Windows die VPN-Verbindung freigeben. Öffnen Sie die Eigenschaften des VPN-Adapters, gehen Sie zu Freigabe und erlauben Sie anderen Netzwerkbenutzern, darüber zu verbinden. Richten Sie die Heimnetzwerkverbindung auf den Hyper-V-Adapter, vEthernet (Default Switch), und testen Sie dann eine neue Anfrage aus dem Gast.

Behandeln Sie die Einrichtung als Laborlösung, denn sie verhält sich wie eine. Sie muss nach einem Trennen, einem erneuten Verbinden oder einem Neustart des Hosts erneut angewendet werden. In einigen Windows-11-Builds fehlt der Adapter ganz im Drop-down, und dann ist dieser Weg geschlossen.

Die Neuinstallation des Hyper-V-Features hat einige hartnäckige Gäste gerettet. Heben Sie sich das für zuletzt auf und notieren Sie zuerst den Gastzustand.

Portweiterleitung, wenn das Subnetz gefiltert wird

Ein Host-VPN, das das NAT-Subnetz des Gasts filtert, bricht den direkten Zugriff statt der Namensauflösung. Die VM läuft, doch ssh [email protected] hängt, während die Übersetzung des Hypervisors weiterhin funktioniert. Leiten Sie die Ports weiter, die die Arbeit braucht, und verbinden Sie sich stattdessen zur Hostadresse. Die Vagrantfile-Zeilen unten decken SSH und einen HTTPS-Dienst ab; beide kommen vor dem Neuladen hinein.

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

Namensauflösung ist eine eigene Entscheidung und verdient eine eigene Korrektur. Aktivieren Sie die Resolver-Funktion des Hosts für diesen NAT-Adapter, oder konfigurieren Sie den internen DNS-Server im Gast von Hand. Den Gast auf einen öffentlichen Resolver zu zeigen lässt das Surfen funktionieren und bricht jeden internen Namen, was schlimmer als der Ausfall ist, weil es wie Erfolg aussieht. Testen Sie einen Namen, den nur der interne Resolver kennt.

Die Prüfung, die Ihnen sagt, dass es funktioniert hat

Führen Sie nach jeder dieser Änderungen eine neue Anfrage aus dem Gast aus, während das Host-VPN verbunden ist, nicht davor. Prüfen Sie die Freigabe nach einem erneuten Verbinden und nach einem Neustart erneut, denn eine Korrektur, die nur eines davon übersteht, ist keine Korrektur. Bestätigen Sie, dass die Resolver-Liste des Gasts zu dem Netzwerk passt, das sein Verkehr tatsächlich nutzt. Testen Sie dann die Portweiterleitung von der Hostadresse aus, denn sie vom Gast aus zu testen beweist nichts. Aus dem Gast decken zwei PowerShell-Prüfungen den Resolver und den weitergeleiteten Port ab:

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

Notieren Sie jede Switch- oder Treiberänderung mit ihrem Rückabwicklungsschritt. Der Microsoft-Leitfaden zu Hyper-V NAT erklärt, was der Default Switch tatsächlich ist, und es lohnt sich, ihn zu lesen, bevor Sie ein zweites NAT-Netzwerk anlegen, das damit kollidiert.