Hyper-V-gæst mister DNS, når værtens VPN opretter forbindelse

Gæsten havde det fint her til morgen. Så startede værten Cisco AnyConnect, og VM'en mistede DNS, sin domænetillid og den delte mappe, uden at noget ændrede sig indeni. En værtstunnel og et gæstenetværk er adskilte veje, og det at forbinde den ene flytter ikke den anden. Arbejd indefra og ud, og skriv ned, hvad du ser, før du ændrer noget.

Hvad gæsten stadig kan se

Noter adressen, standardgatewayen og resolveren i VM'en, én gang før værten opretter forbindelse og én gang efter. En gæst, der beholdt sin adresse og kun mistede navneopløsningen, har et resolverproblem. En gæst, der aldrig havde en rute, har et vejproblem, og de to kræver forskelligt arbejde. Fra værten kan du ikke skelne dem, og derfor skal aflæsningen komme indefra.

De tre aflæsninger, taget to gange, er din baseline. Alt senere måles mod dem.

Hvilken udgang gæsten bruger

Hyper-V svarer på det med to kommandoer: Get-VMSwitch viser switchne, og Get-VMNetworkAdapter -VMName TestVM viser den, som gæsten er knyttet til. Default Switch er et NAT-netværk, som Windows administrerer; en ekstern switch giver trafik til en fysisk adapter; en intern switch bærer intet, før nogen tilføjer NAT eller en router. VirtualBox præsenterer de samme tre idéer som NAT, NAT Network og bridged.

Tilstanden afgør, om værtens tunnel overhovedet kan betyde noget. En NAT-gæst oversættes af WinNAT og videresendes derefter af værtens stak, så den følger værtens rutetabel; med en full-tunnel-klient er dens trafik den trafik, der går ind i VPN-adapteren, og den droppes, når klienten blokerer det lokale undernet. En broet gæst på en ekstern switch når aldrig værtens routing: dens rammer forlader det fysiske NIC direkte, så den omgår både tunnelen og klientens lokalnetspolitik.

Del værtens tunnel med Hyper-V

Hvis gæsten har brug for tunnelen og ikke kan køre sin egen klient, kan Windows dele VPN-forbindelsen. Åbn VPN-adapterens egenskaber, gå til Deling, og tillad andre netværksbrugere at oprette forbindelse gennem den. Peg hjemmenetværksforbindelsen mod Hyper-V-adapteren, vEthernet (Default Switch), og test derefter en ny anmodning indefra gæsten.

Behandl arrangementet som en laboratorieløsning, fordi den opfører sig som en. Den skal anvendes igen efter en afbrydelse, en genoprettelse af forbindelsen eller en genstart af værten. I nogle Windows 11-builds mangler adapteren helt i rullemenuen, og så er denne vej lukket.

Geninstallation af Hyper-V-funktionen har reddet et par stædige gæster. Gem det til sidst, og noter gæstens tilstand først.

Portvideresendelse, når undernettet er filtreret

En vært-VPN, der filtrerer gæstens NAT-undernet, bryder direkte adgang frem for navneopløsning. VM'en kører, men ssh [email protected] hænger, mens hypervisorens oversættelse stadig virker. Videresend de porte, arbejdet har brug for, og forbind til værtens adresse i stedet. Vagrantfile-linjerne nedenfor dækker SSH og én HTTPS-tjeneste; begge indsættes før genindlæsningen.

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

Navneopløsning er en separat beslutning og fortjener sin egen rettelse. Slå værtens resolverfunktion til for den NAT-adapter, eller konfigurer den interne DNS-server inde i gæsten manuelt. Hvis gæsten peges på en offentlig resolver, virker browsing, og hvert internt navn brydes, hvilket er værre end afbrydelsen, fordi det ligner succes. Test et navn, som kun den interne resolver kender.

Kontrollen, der fortæller dig, at det virkede

Efter enhver af disse ændringer skal du køre en ny anmodning indefra gæsten med værtens VPN tilsluttet, ikke før. Kontroller delingen igen efter en genoprettelse af forbindelsen og efter en genstart, fordi en rettelse, der kun overlever en af dem, ikke er en rettelse. Bekræft, at gæstens resolverliste svarer til det netværk, dens trafik faktisk bruger. Test derefter portvideresendelsen fra værtens adresse, fordi det ikke beviser noget at teste den fra gæsten. Indefra gæsten dækker to PowerShell-kontroller resolveren og den videresendte port:

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

Noter hver switch- eller driverændring med dens fortrydelsestrin. Microsofts Hyper-V NAT-vejledning forklarer, hvad Default Switch faktisk er, og den er værd at læse, før du opretter et andet NAT-netværk, der er i konflikt med det.