Hyper-V-gast verliest DNS wanneer de VPN van de host verbindt

De gast deed het vanochtend prima. Toen startte de host Cisco AnyConnect en de VM verloor DNS, het domeinvertrouwen en de gedeelde map, zonder dat er binnenin iets veranderde. Een hosttunnel en een gastnetwerk zijn gescheiden paden, en het ene verbinden verplaatst het andere niet. Werk van binnen de gast naar buiten, en noteer wat je ziet voordat je iets verandert.

Wat de gast nog kan zien

Noteer het adres, de standaardgateway en de resolver in de VM, één keer voordat de host verbindt en één keer daarna. Een gast die zijn adres behield en alleen naamresolutie verloor, heeft een resolverprobleem. Een gast die nooit een route had, heeft een padprobleem, en beide vragen ander werk. Vanaf de host kun je ze niet onderscheiden, daarom moet de meting van binnenuit komen.

Die drie metingen, twee keer gedaan, zijn je basislijn. Alles daarna wordt ertegen afgemeten.

Welke uitgang de gast gebruikt

Hyper-V beantwoordt dit met twee opdrachten: Get-VMSwitch somt de switches op, en Get-VMNetworkAdapter -VMName TestVM toont degene waaraan de gast is gekoppeld. De Default Switch is een NAT-netwerk dat Windows beheert; een externe switch geeft het verkeer aan een fysieke adapter; een interne switch draagt niets tot iemand NAT of een router toevoegt. VirtualBox presenteert dezelfde drie ideeën als NAT, NAT Network en bridged.

De modus bepaalt of de hosttunnel überhaupt iets kan uitmaken. Een NAT-gast wordt door WinNAT vertaald en daarna door de hoststack doorgestuurd, dus volgt hij de routetabel van de host; met een full-tunnelclient is zijn verkeer het verkeer dat de VPN-adapter binnenkomt, en het wordt weggegooid wanneer de client het lokale subnet blokkeert. Een gebrugde gast op een externe switch bereikt nooit de routing van de host: zijn frames verlaten de fysieke NIC rechtstreeks, dus hij omzeilt zowel de tunnel als het local-LAN-beleid van de client.

De hosttunnel delen met Hyper-V

Als de gast de tunnel nodig heeft en geen eigen client kan draaien, kan Windows de VPN-verbinding delen. Open de eigenschappen van de VPN-adapter, ga naar Delen, en sta andere netwerkgebruikers toe erdoor te verbinden. Wijs de thuisnetwerkverbinding aan de Hyper-V-adapter toe, vEthernet (Default Switch), en test daarna een nieuw verzoek van binnen de gast.

Behandel deze opstelling als een laboratoriumoplossing, want zo gedraagt hij zich. Hij moet opnieuw worden toegepast na een verbreking, een herverbinding of een herstart van de host. In sommige Windows 11-builds ontbreekt de adapter volledig in de vervolgkeuzelijst, en dan is deze route gesloten.

Het opnieuw installeren van de Hyper-V-functie heeft een paar koppige gasten gered. Bewaar dat voor het laatst, en noteer eerst de toestand van de gast.

Portdoorgifte wanneer het subnet wordt gefilterd

Een host-VPN dat het NAT-subnet van de gast filtert, breekt directe toegang in plaats van naamresolutie. De VM draait, maar ssh [email protected] hangt, terwijl de vertaling van de hypervisor nog werkt. Stuur de poorten door die het werk nodig heeft en verbind in plaats daarvan met het hostadres. De Vagrantfile-regels hieronder dekken SSH en één HTTPS-dienst; beide gaan erin vóór het herladen.

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

Naamresolutie is een aparte beslissing en verdient een eigen oplossing. Schakel de resolverfunctie van de host in voor die NAT-adapter, of configureer de interne DNS-server in de gast handmatig. De gast naar een openbare resolver wijzen laat browsen werken en breekt elke interne naam, wat erger is dan de storing omdat het op succes lijkt. Test een naam die alleen de interne resolver kent.

De controle die je vertelt dat het werkte

Voer na een van deze wijzigingen een nieuw verzoek uit van binnen de gast terwijl de host-VPN verbonden is, niet daarvoor. Controleer het delen opnieuw na een herverbinding en na een herstart, want een oplossing die slechts één van beide overleeft is geen oplossing. Bevestig dat de resolverlijst van de gast overeenkomt met het netwerk dat zijn verkeer echt gebruikt. Test daarna de portdoorgifte vanaf het hostadres, want die vanuit de gast testen bewijst niets. Van binnen de gast dekken twee PowerShell-controles de resolver en de doorgestuurde poort:

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

Noteer elke switch- of stuurprogrammawijziging met de bijbehorende terugdraaistap. De Microsoft-gids over Hyper-V NAT legt uit wat de Default Switch werkelijk is, en het is de moeite waard die te lezen voordat je een tweede NAT-netwerk maakt dat ermee in conflict komt.