Hyper-V-gjest mister DNS når vertens VPN kobler til

Gjesten hadde det fint i morges. Så startet verten Cisco AnyConnect, og VM-en mistet DNS, domenetillit og den delte mappen, uten at noe endret seg inni den. En vertstunnel og et gjestenettverk er atskilte veier, og å koble til den ene flytter ikke den andre. Arbeid innenfra og ut, og skriv ned det du ser før du endrer noe.

Hva gjesten fortsatt kan se

Noter adressen, standardgatewayen og resolveren i VM-en, én gang før verten kobler til og én gang etterpå. En gjest som beholdt adressen og bare mistet navneoppslag, har et resolverproblem. En gjest som aldri hadde en rute, har et veiproblem, og de to krever ulikt arbeid. Fra verten kan du ikke skille dem, derfor må avlesningen komme innenfra.

De tre avlesningene, tatt to ganger, er utgangspunktet ditt. Alt senere måles mot dem.

Hvilken utgang gjesten bruker

Hyper-V svarer på dette med to kommandoer: Get-VMSwitch viser svitsjene, og Get-VMNetworkAdapter -VMName TestVM viser den gjesten er knyttet til. Default Switch er et NAT-nettverk som Windows administrerer; en ekstern svitsj gir trafikken til en fysisk adapter; en intern svitsj bærer ingenting før noen legger til NAT eller en ruter. VirtualBox presenterer de samme tre ideene som NAT, NAT Network og bridged.

Modusen avgjør om vertstunnelen i det hele tatt kan ha betydning. En NAT-gjest oversettes av WinNAT og videresendes deretter av vertsstakken, så den følger vertens rutetabell; med en full-tunnel-klient er trafikken dens den trafikken som går inn i VPN-adapteren, og den droppes når klienten blokkerer det lokale subnettet. En broet gjest på en ekstern svitsj når aldri vertens ruting: rammene forlater den fysiske NIC-en direkte, så den omgår både tunnelen og klientens lokalnettspolicy.

Dele vertstunnelen med Hyper-V

Hvis gjesten trenger tunnelen og ikke kan kjøre sin egen klient, kan Windows dele VPN-tilkoblingen. Åpne egenskapene til VPN-adapteren, gå til Deling, og la andre nettverksbrukere koble til gjennom den. Pek hjemmenettverkstilkoblingen mot Hyper-V-adapteren, vEthernet (Default Switch), og test deretter en ny forespørsel innenfra gjesten.

Behandle ordningen som en laboratoriefiks, fordi den oppfører seg som en. Den må brukes på nytt etter en frakobling, en gjentilkobling eller en omstart av verten. I noen Windows 11-bygg mangler adapteren helt i rullegardinlisten, og da er denne veien stengt.

Reinstallering av Hyper-V-funksjonen har reddet noen sta gjester. Spar det til sist, og noter gjestens tilstand først.

Portvideresending når subnettet er filtrert

En verts-VPN som filtrerer gjestens NAT-subnett bryter direkte tilgang, ikke navneoppslag. VM-en kjører, men ssh [email protected] henger, mens hypervisorens oversettelse fortsatt virker. Videresend portene arbeidet trenger, og koble til vertsadressen i stedet. Vagrantfile-linjene nedenfor dekker SSH og én HTTPS-tjeneste; begge legges inn før omlastingen.

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

Navneoppslag er en egen beslutning og fortjener sin egen retting. Slå på vertens resolverfunksjon for den NAT-adapteren, eller konfigurer den interne DNS-serveren inne i gjesten manuelt. Å peke gjesten mot en offentlig resolver gjør nettlesingen virke og bryter hvert internt navn, noe som er verre enn avbruddet fordi det ser ut som suksess. Test et navn som bare den interne resolveren kjenner.

Sjekken som forteller deg at det virket

Etter en av disse endringene, kjør en ny forespørsel innenfra gjesten med vertens VPN tilkoblet, ikke før. Kontroller delingen på nytt etter en gjentilkobling og etter en omstart, fordi en rettelse som bare overlever én av dem, ikke er en rettelse. Bekreft at gjestens resolverliste samsvarer med nettverket trafikken faktisk bruker. Test deretter portvideresendingen fra vertsadressen, fordi å teste den fra gjesten ikke beviser noe. Innenfra gjesten dekker to PowerShell-sjekker resolveren og den videresendte porten:

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

Noter hver svitsj- eller driverendring med tilbakekallingssteget. Microsofts Hyper-V NAT-veiledning forklarer hva Default Switch faktisk er, og den er verdt å lese før du lager et nytt NAT-nettverk som kolliderer med det.