Bruger en Hyper-V-virtuel maskine værtens VPN? Det afhænger af switchen

Installer en VPN-klient på Hyper-V-værten, åbn en browser der, og udgangsadressen ændrer sig; åbn den samme side inde i den virtuelle maskine, og den viser måske den gamle adresse eller slet intet. Den sædvanlige konklusion er, at den virtuelle maskine er i stykker, eller at der skal slås delt tunneltrafik til. Ingen af delene følger. En VPN-klient er ikke en egenskab ved maskinen; den er et sæt ruter, en virtuel adapter og ofte et filter knyttet til bestemte grænseflader. Om gæstetrafik nogensinde møder det maskineri, afhænger af den virtuelle switch, som gæsten bruger.

Myten, sagt ligeud

Troen er, at en VPN installeret på værten beskytter hele maskinen, inklusive virtuelle maskiner, fordi en virtuel maskine blot er en proces, der kører på den maskine. Det er en behagelig tro, fordi antivirus og værtens firewalls normalt opfører sig sådan. Netværksveje gør ikke.

En gæstes ramme berøres kun af værtens VPN-stak, hvis værten router eller filtrerer den. Skriv den sætning på en gul seddel, fordi hvert tilfælde nedenfor er en variation af den.

Tre switchtyper, tre veje

En ekstern switch binder en virtuel adapter til et fysisk netværkskort, og gæsten sender rammer gennem den binding med sin egen MAC-adresse. Gæsten bliver en jævnbyrdig deltager på det fysiske netværk med sin egen DHCP-leje, gateway og DNS-servere. Værtens VPN-standardrute ligger i værtens stak og flytter ikke de rammer, fordi de broes i stedet for at routes gennem værten. Det er også derfor, en ekstern switch over en Wi-Fi-adapter er en dårlig idé: de fleste trådløse drivere transporterer ikke rammer for en anden MAC-adresse.

En intern switch forbinder gæster til en virtuel adapter på værten. I sig selv giver den ingen internetudgang; et NAT-objekt på værten sørger for oversættelse, som beskrevet i Hyper-Vs NAT-vejledning. Nu kommer gæstens pakker faktisk ind i værtens routing og NAT-vej, så VPN-klientens ruter og filtre betyder igen noget. Det er den ordning, hvor den virtuelle maskine virkelig følger værtens VPN, og hvor en kill switch kan skære gæsten helt fra.

En privat switch har ingen værtsadapter og ingen uplink. Gæster taler med hinanden og med intet andet, så hvis en virtuel maskine på en privat switch ikke har internet, er den manglende router årsagen, og VPN er irrelevant.

Standardswitchen er sin egen ordning

Windows leverer en standardswitch, der kombinerer en intern switch med NAT og en DNS-proxy. Dens undernet vælges af værten, kan ændre sig efter genstart, og er ikke det samme objekt som et NAT-netværk, du selv opretter. At genopbygge den, som om det var et laboratorienetværk, er hvordan folk ender med to NAT'er og en gæst, der stadig ikke har nogen rute.

Hvis den virtuelle maskine ligger på standardswitchen, så læs den adresse, gæsten fik, og sammenlign den med værtens NAT-tabel, før du rører VPN-klienten. Uoverensstemmelse mellem gæstens gateway og NAT-præfikset forklarer flere fejl end nogen klientindstilling.

Fire fakta, der afgør spørgsmålet

Indsaml disse, før du ændrer noget: switchens type og dens uplink, adapteren knyttet til den virtuelle maskine, gæstens egen adresse, gateway og DNS samt værtens NAT- og standardrutetilstand. Kommandoerne, der kun læser, er Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, og Get-NetRoute -DestinationPrefix 0.0.0.0/0; og inde i gæsten giver ipconfig /all resten.

Beslut derefter, hvad gæsten skal gøre. Hvis den skal blive uden for VPN'en, så skaf udbyderens understøttede undtagelse for netop den vej, fordi en undtagelse for en eksekverbar fil på værten ikke fritager videresendt trafik fra den virtuelle maskine. Hvis den skal bruge VPN'en, så bekræft klientens dokumenterede håndtering af trafik fra virtuelle maskiner i stedet for at antage, at en test i værtens browser dækker det.

En test inde i gæsten er det eneste bevis, der tæller. Tjek udgangsadressen fra gæsten, slå et internt navn op, genopret VPN-forbindelsen og gentag. Værtens browserresultat er ikke en erstatning for noget af det.

Hvad myten koster

Folk slår kill switch fra, tilføjer statiske ruter eller sletter og genskaber switches bare for at få en test til at bestå. Hver genvej ændrer fejlmåden: gæsten kan nå internettet ad en vej, ingen havde tænkt på, eller værten kan miste forbindelsen, når en ekstern switch genbinder sit fysiske kort.

Genbinding af en ekstern switch afbryder værtens egen adgang, så hold en out-of-band-vej åben, og undgå at slette switches, mens du stadig diagnosticerer. Det korrekte resultat er gæstens tilsigtede vej, inklusive hvordan den genopretter forbindelsen, og hvordan den fejler, ikke et grønt hak fra én sideindlæsning.

Det holdbare svar er én linje per virtuel maskine i fortegnelsen: hvilken switch den bruger, og hvilken komponent der leverer dens gateway. Når det er skrevet ned, er den næste VPN-ændring et opslag i stedet for en eftermiddag med gætterier.