Använder en Hyper-V VM värdens VPN? Det beror på växeln

Installera en VPN-klient på Hyper-V-värden, öppna en webbläsare där och ut adressen ändras; öppna samma sida inne i den virtuella datorn och den kan visa den gamla adressen, eller ingenting. Den vanliga slutsatsen är att den virtuella datorn är trasig, eller att delad tunnling måste aktiveras. Ingen av dem följer. En VPN-klient är inte en egenskap hos maskinen; den är en uppsättning rutter, en virtuell adapter och ofta ett filter kopplat till specifika gränssnitt. Om gästtrafiken någonsin möter den maskineriet beror på den virtuella växel som gästen använder.

Myten, sagt rakt ut

Tron är att en VPN installerad på värden skyddar hela maskinen, inklusive virtuella datorer, eftersom en virtuell dator bara är en process som körs på den maskinen. Det är en bekväm tro, eftersom antivirus och värdens brandväggar vanligtvis beter sig så. Nätverksvägar gör det inte.

En gästs ram berörs bara av värdens VPN-stack om värden dirigerar eller filtrerar den. Skriv den meningen på en lapp, för varje fall nedan är en variant av den.

Tre växeltyper, tre vägar

En extern växel binder en virtuell adapter till ett fysiskt nätverkskort, och gästen skickar ramar genom den bindningen med sin egen MAC-adress. Gästen blir en jämlike på det fysiska nätverket, med egen DHCP-lease, gateway och DNS-servrar. Värdens standardrutt för VPN ligger i värdstacken och flyttar inte de ramarna, eftersom de bryggas i stället för att dirigeras genom värden. Det är också därför en extern växel över en Wi-Fi-adapter är en dålig idé: de flesta trådlösa drivrutiner tar inte ramar för en andra MAC-adress.

En intern växel kopplar gäster till en virtuell adapter på värden. Ensam ger den ingen internetutgång; ett NAT-objekt på värden sköter översättningen, som beskrivs i guiden för NAT i Hyper-V. Nu kommer gästens paket in i värdens routing och NAT-väg, så VPN-klientens rutter och filter spelar roll igen. Det är den ordning där den virtuella datorn verkligen följer värdens VPN, och där en kill switch kan stänga av gästen helt.

En privat växel har ingen värdadapter och ingen upplänk. Gäster pratar bara med varandra, så om en virtuell dator på en privat växel saknar internet är den saknade routern orsaken och VPN:en är irrelevant.

Standardväxeln är en egen ordning

Windows levererar en standardväxel som kombinerar en intern växel med NAT och en DNS-proxy. Dess subnät väljs av värden, kan ändras efter omstarter och är inte samma objekt som ett NAT-nätverk du skapar själv. Att bygga om den som om den vore ett labbnät är hur folk hamnar med två NAT:ar och en gäst som fortfarande saknar rutt.

Om den virtuella datorn sitter på standardväxeln, läs adressen som gästen fick och jämför den med värdens NAT-tabell innan du rör VPN-klienten. En missmatchning mellan gästens gateway och NAT-prefixet förklarar fler fel än någon klientinställning.

Fyra fakta som avgör frågan

Samla dessa innan du ändrar något: växeltypen och dess upplänk, adaptern som är kopplad till den virtuella datorn, gästens egen adress, gateway och DNS, samt värdens NAT- och standardrutt-tillstånd. Skrivskyddade kommandon är Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat och Get-NetRoute -DestinationPrefix 0.0.0.0/0; inne i gästen ger ipconfig /all resten.

Bestäm sedan vad gästen ska göra. Om den ska stanna utanför VPN:en, skaffa leverantörens dokumenterade undantag för just den vägen, eftersom att utesluta en värdkörbar fil inte undantar vidarebefordrad VM-trafik. Om den ska använda VPN:en, bekräfta klientens dokumenterade hantering av VM-trafik i stället för att anta att ett webbläsartest på värden täcker det.

Ett test inne i gästen är det enda bevis som räknas. Kontrollera utgångsadressen från gästen, slå upp ett internt namn, återanslut VPN:en och upprepa. Värdens webbläsarresultat är ingen ersättning för något av det.

Vad myten kostar

Folk stänger av kill switch, lägger till statiska rutter eller raderar och återskapar växlar bara för att ett test ska gå igenom. Varje genväg ändrar felmoden: gästen kan nå internet via en väg ingen avsåg, eller värden kan tappa anslutningen när en extern växel binder om sitt fysiska nätverkskort.

Om bindningen av en extern växel avbryter värdens egen åtkomst, så håll en väg utanför bandet öppen och undvik att radera växlar medan du fortfarande diagnostiserar. Rätt utfall är gästens avsedda väg, inklusive hur den återansluter och hur den misslyckas, inte en grön bock från en sidladdning.

Det hållbara svaret är en rad per virtuell dator i inventariet: vilken växel den använder och vilken komponent som ger den gateway. Med det nedskrivet är nästa VPN-ändring en uppslagning i stället för en eftermiddag av gissningar.