Bruker en Hyper-V-virtuell maskin vertens VPN? Det avhenger av svitsjen

Installer en VPN-klient på Hyper-V-verten, åpne en nettleser der, og utgangsadressen endres; åpne samme side inne i den virtuelle maskinen, og den kan vise den gamle adressen, eller ingenting i det hele tatt. Den vanlige konklusjonen er at den virtuelle maskinen er ødelagt, eller at delt tunnelering må slås på. Ingen av delene følger. En VPN-klient er ikke en egenskap ved maskinen; den er et sett med ruter, en virtuell adapter og ofte et filter knyttet til bestemte grensesnitt. Om gjestetrafikk noen gang møter denne maskineriet, avhenger av den virtuelle svitsjen gjesten bruker.

Myten, sagt rett ut

Troen er at en VPN installert på verten beskytter hele maskinen, virtuelle maskiner inkludert, fordi en virtuell maskin bare er en prosess som kjører på den maskinen. Det er en behagelig tro, fordi antivirus og vertens brannmurer vanligvis oppfører seg slik. Nettverksveier gjør det ikke.

En gjests ramme berøres bare av vertens VPN-stack hvis verten ruter eller filtrerer den. Skriv den setningen på en lapp, fordi hvert tilfelle nedenfor er en variant av den.

Tre svitsjtyper, tre veier

En ekstern svitsj binder en virtuell adapter til et fysisk nettverkskort, og gjesten sender rammer gjennom den bindingen med sin egen MAC-adresse. Gjesten blir en jevnbyrdig deltaker på det fysiske nettverket, med egen DHCP-leie, gateway og DNS-servere. Vertens VPN-standardrute ligger i vertens stack og flytter ikke disse rammene, fordi de brues i stedet for å rutes gjennom verten. Det er også derfor en ekstern svitsj over en Wi-Fi-adapter er en dårlig idé: de fleste trådløse drivere frakter ikke rammer for en andre MAC-adresse.

En intern svitsj kobler gjester til en virtuell adapter på verten. Alene gir den ingen internettutgang; et NAT-objekt på verten sørger for oversettelse, som beskrevet i Hyper-Vs NAT-veiledning. Nå kommer gjestens pakker faktisk inn i vertens ruting og NAT-vei, så VPN-klientens ruter og filtre betyr noe igjen. Dette er oppsettet der den virtuelle maskinen virkelig følger vertens VPN, og der en kill switch kan kutte gjesten helt av.

En privat svitsj har ingen vertsadapter og ingen uplink. Gjester snakker med hverandre og med ingenting annet, så hvis en virtuell maskin på en privat svitsj ikke har internett, er den manglende ruteren årsaken, og VPN er irrelevant.

Standardsvitsjen er sitt eget oppsett

Windows leverer en standardsvitsj som kombinerer en intern svitsj med NAT og en DNS-proxy. Undernettet velges av verten, kan endre seg etter omstart, og er ikke det samme objektet som et NAT-nettverk du oppretter selv. Å bygge den på nytt som om det var et laboratorienettverk, er hvordan folk ender med to NAT-er og en gjest som fortsatt ikke har noen rute.

Hvis den virtuelle maskinen ligger på standardsvitsjen, les adressen gjesten fikk, og sammenlign den med vertens NAT-tabell før du rører VPN-klienten. Avvik mellom gjestens gateway og NAT-prefikset forklarer flere feil enn noen klientinnstilling.

Fire fakta som avgjør spørsmålet

Samle disse før du endrer noe: svitsjtypen og dens uplink, adapteren knyttet til den virtuelle maskinen, gjestens egen adresse, gateway og DNS, samt vertens NAT- og standardrutetilstand. Kommandoene som bare leser, er Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, og Get-NetRoute -DestinationPrefix 0.0.0.0/0; og inne i gjesten gir ipconfig /all resten.

Avgjør deretter hva gjesten skal gjøre. Hvis den skal holde seg utenfor VPN-en, skaff leverandørens støttede unntak for nøyaktig den veien, fordi unntak for en kjørbar fil på verten ikke fritar videresendt trafikk fra den virtuelle maskinen. Hvis den skal bruke VPN-en, bekreft klientens dokumenterte håndtering av virtuell maskin-trafikk i stedet for å anta at en test i vertens nettleser dekker det.

En test inne i gjesten er det eneste beviset som teller. Sjekk utgangsadressen fra gjesten, løs opp et internt navn, koble til VPN-en på nytt og gjenta. Vertens nettleserresultat erstatter ingenting av dette.

Hva myten koster

Folk slår av kill switch, legger til statiske ruter eller sletter og gjenoppretter svitsjer bare for å få en test til å bestå. Hver snarvei endrer feilmodusen: gjesten kan nå internett via en vei ingen hadde tenkt på, eller verten kan miste tilkoblingen når en ekstern svitsj binder det fysiske kortet på nytt.

Å binde en ekstern svitsj på nytt avbryter vertens egen tilgang, så hold en ut-av-bånd-vei åpen og unngå å slette svitsjer mens du fortsatt feilsøker. Det riktige resultatet er gjestens tiltenkte vei, inkludert hvordan den kobler til på nytt og hvordan den feiler, ikke en grønn hake fra én sideinnlasting.

Det varige svaret er én linje per virtuell maskin i oversikten: hvilken svitsj den bruker, og hvilken komponent som leverer gatewayen. Når det er skrevet ned, er den neste VPN-endringen et oppslag i stedet for en ettermiddag med gjetting.