Brukar ein Hyper-V-virtuell maskin VPN-en til verten? Det kjem an på svitsjen

Installer ein VPN-klient på Hyper-V-verten, opne ein nettlesar der, og utgangsadressa endrar seg; opne same side inne i den virtuelle maskinen, og ho kan vise den gamle adressa, eller ingenting i det heile. Den vanlege konklusjonen er at den virtuelle maskinen er øydelagd, eller at delt tunnelering må slåast på. Ingen av delane følgjer. Ein VPN-klient er ikkje ein eigenskap ved maskinen; han er eit sett med ruter, ein virtuell adapter og ofte eit filter knytt til bestemte grensesnitt. Om gjestetrafikk nokon gong møter dette maskineriet, kjem an på den virtuelle svitsjen gjesten brukar.

Myten, sagt rett ut

Trua er at ein VPN installert på verten vernar heile maskinen, virtuelle maskinar inkluderte, fordi ein virtuell maskin berre er ein prosess som køyrer på den maskinen. Det er ei behageleg tru, fordi antivirus og brannmurar på verten vanlegvis oppfører seg slik. Nettverksvegar gjer det ikkje.

Ramma til ein gjest blir berre rørt av VPN-stakken til verten om verten ruter eller filtrerer henne. Skriv den setninga på ein lapp, fordi kvart tilfelle nedanfor er ein variant av henne.

Tre svitsjtypar, tre vegar

Ein ekstern svitsj bind ein virtuell adapter til eit fysisk nettverkskort, og gjesten sender rammer gjennom den bindinga med si eiga MAC-adresse. Gjesten blir ein jamlike pa det fysiske nettet, med eiga DHCP-leige, gateway og DNS-tenarar. Standardruta til VPN-en på verten ligg i stakken til verten og flyttar ikkje desse rammene, fordi dei blir brua i staden for ruta gjennom verten. Det er også difor ein ekstern svitsj over ein Wi-Fi-adapter er ein dårleg idé: dei fleste trådlause drivarane fraktar ikkje rammer for ei andre MAC-adresse.

Ein intern svitsj knyter gjester til ein virtuell adapter på verten. Åleine gir han ingen internettutgang; eit NAT-objekt på verten sørgjer for omsetjing, som skildra i Hyper-V-NAT-rettleiinga. No kjem pakkane til gjesten faktisk inn i rutinga og NAT-vegen til verten, så rutene og filtra til VPN-klienten tel igjen. Dette er oppsettet der den virtuelle maskinen verkeleg følgjer VPN-en til verten, og der ein kill switch kan kutte gjesten heilt av.

Ein privat svitsj har ingen vertsadapter og ingen uplink. Gjester snakkar med kvarandre og med ingenting anna, så om ein virtuell maskin på ein privat svitsj ikkje har internett, er den manglande rutaren årsaka, og VPN-en er irrelevant.

Standardsvitsjen er sitt eige oppsett

Windows leverer ein standardsvitsj som kombinerer ein intern svitsj med NAT og ein DNS-proxy. Underdelen blir vald av verten, kan endre seg etter omstart, og er ikkje det same objektet som eit NAT-nettverk du lagar sjølv. Å byggje han opp att som om det var eit laboratorienettverk, er korleis folk endar med to NAT-ar og ein gjest som framleis ikkje har noka rute.

Om den virtuelle maskinen ligg på standardsvitsjen, les adressa gjesten fekk, og samanlikn henne med NAT-tabellen til verten før du rører VPN-klienten. Avvik mellom gatewayen til gjesten og NAT-prefikset forklarar fleire feil enn noka klientinnstilling.

Fire fakta som avgjer spørsmålet

Samle desse før du endrar noko: svitsjtypen og uplinken hans, adapteren knytt til den virtuelle maskinen, den eigne adressa, gatewayen og DNS-en til gjesten, og NAT- og standardrutetilstanden til verten. Kommandoane som berre les, 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.

Avgjer så kva gjesten skal gjere. Om han skal halde seg utanfor VPN-en, skaff den støtta unntaket frå leverandøren for nøyaktig den vegen, fordi unntak for ei køyrbar fil på verten fritek ikkje vidaresend trafikk frå den virtuelle maskinen. Om han skal bruke VPN-en, stadfest den dokumenterte handsaminga til klienten av virtuell maskin-trafikk i staden for å anta at ein test i nettlesaren til verten dekkjer det.

Ein test inne i gjesten er det einaste beviset som tel. Sjekk utgangsadressa frå gjesten, løys opp eit internt namn, kople VPN-en til på nytt og gjenta. Nettlesarresultatet til verten erstattar ingenting av dette.

Kva myten kostar

Folk slår av kill switch, legg til statiske ruter eller slettar og gjenopprettar svitsjar berre for å få ein test til å gå gjennom. Kvar snarveg endrar feilmodusen: gjesten kan nå internett via ein veg ingen hadde tenkt på, eller verten kan miste tilkoplinga når ein ekstern svitsj bind det fysiske kortet på nytt.

Å binde ein ekstern svitsj på nytt avbryt den eigne tilgangen til verten, så hald ein ut-av-band-veg open og unngå å slette svitsjar medan du framleis feilsøkjer. Det rette resultatet er den tiltenkte vegen til gjesten, inkludert korleis han koplar til på nytt og korleis han feilar, ikkje ein grøn hake frå éi sideinnlasting.

Det varige svaret er éi line per virtuell maskin i oversikta: kva svitsj ho brukar, og kva komponent som leverer gatewayen hennar. Når det er skrive ned, er den neste VPN-endringa eit oppslag i staden for ein ettermiddag med gjetting.