Köra VPN på värden eller inuti VM:en? Beslutsvägledning

Att bygga tunneln inuti gästen och att bygga den på värden ändrar båda den adress en webbläsare rapporterar, och där slutar likheten. En gästägd tunnel behåller sina nycklar, sin standardrutt och sin resolver i gästens kärna, medan värden vidarebefordrar krypterade paket till en enda fjärradress. En värdägd tunnel är spegelbilden: värdens klient håller sessionen och tillämpar rutter och policy, och gästen lånar det som kommer ut. Väljer du fel ägare skickar varje senare symptom dig till fel maskin. Två kommandon avgör frågan på ungefär en minut, och resten av den här vägledningen är vad du gör med svaret.

Bestäm ägaren innan du rör klienten

Regeln handlar om var chiffertexten produceras, inte om vilken maskin som visar en VPN-ikon. Om gästen producerar den behöver gästen en fungerande rutt till VPN-servern och inget annat från värden. Om värden producerar den måste gästens väg genom värden överleva vilken policy som helst som värdens klient lägger på lokal trafik.

Tre frågor väljer oftast placeringen åt dig. Måste gästens trafik överleva en företagsklient på värden? Då hör tunneln hemma i gästen. Behöver flera gäster en enda inloggning och en enda utgångsadress? Då hör den hemma på värden, med vidarebefordran medvetet inställd. Ska gästens trafik hållas helt utanför värdens VPN? Då är en gästtunnel det enda arrangemang som ger dig det genom konstruktionen.

Skriv ner svaret som en rad bredvid VM-namnet: guest-owned eller host-owned. I ett labb med sex maskiner sparar den noten mer tid än något steg nedan, eftersom den hindrar dig från att felsöka en tunnel som aldrig fanns i maskinen du är inloggad på.

WSL1 och WSL2 är motsatta fall

WSL1 är inte en virtuell maskin, så placeringsfrågan förångas mestadels. Dess Linux-binärer kör mot Windows nätverksstack genom ett översättningslager, och en Linux-VPN-klient har inga oberoende gränssnitt att konfigurera. Det som fungerar är en tunnel på Windows-sidan, där distributionen använder resultatet utan att äga något.

WSL2 är det motsatta. Det kör en riktig kärna i en lätt hjälp-VM bakom en virtuell Hyper-V-växel, och dess adressrymd NAT:as genom en adapter på värdsidan. En Linux-klient inuti distributionen beter sig därför som på en fysisk Linux-låda: den skapar tun0 eller wg0, installerar sina egna rutter och fungerar. Felet bor på värdsidan. När en Windows-VPN-klient ansluter med en policy som blockerar trafik på lokala nätverk behandlar den WSL2-subnätet som ett ej betrott lokalt nätverk och skär av NAT-vägen. Distributionen förlorar då DNS och utgående åtkomst medan dess egen tunnel fortfarande är frisk: wg show rapporterar ett handslag, ip route ser korrekt ut, och curl hänger.

Vilken rättelse du kan använda beror på Windows-versionen. Den äldre är ett undantag i värdens klient för WSL-subnätet, tillagt under klientens inställningar för lokalt nätverk eller delad tunnel. Den nyare, på Windows 11-versioner som stöder den, är speglat nätverk: sätt networkingMode=mirrored i [wsl2]-avsnittet i %UserProfile%\.wslconfig, kör wsl --shutdown, och distributionen delar värdens gränssnitt i stället för ett privat NAT-subnät. Speglat läge ändrar också hur localhost och inkommande portar beter sig, så behandla det som en migrering och inte som en strömbrytare.

NAT, brygga och vad värden kan se

Under NAT adresseras gästens tunnelpaket till VPN-serverns offentliga adress och lämnar värdadaptern som krypterad UDP eller TCP. Värden ser ett enda flöde och dess bytant, ingenting om destinationerna inuti. Under en bryggad adapter har gästen sin egen identitet på lager 2 på det fysiska LAN:et, tar sin egen DHCP-lease och ser för varje MAC-baserad policy ut som en andra enhet. Ingen av lägena låter värden läsa tunnelns nyttolast; den bryggade gästen är helt enkelt mycket mer synlig för nätverket runt omkring.

Isoleringen har också en nedre gräns. En gäst kan inte gömma sig för maskinen som äger dess minne, och den som kontrollerar värden kan läsa nycklar ur gästens RAM. Det en gästtunnel ger dig är en rutt- och malwaregräns, inte skydd mot personen som håller i den bärbara datorn. De dokumenterade adapterlägena är värda att ha öppna medan du väljer, eftersom läget ändrar både vad värden ser och vad LAN:et ser.

Vägledning: placera den, konfigurera den, bevisa det

Kör dessa fyra kontroller i ordning i ett färskt gästskal, och stanna vid den första som inte stämmer med ägaren du skrev ner.

1. ip route get 1.1.1.1 som returnerar tun0 eller wg0 betyder gästägd; eth0 med ett privat nästa hopp betyder värdägd.
2. resolvectl query example.com, eller läs /etc/resolv.conf där gästen inte kör någon resolvertjänst. En tunnel som bär trafik men inte DNS är det vanligaste halvkonfigurerade tillståndet.
3. Jämför utgångarna: curl -4 -s https://ifconfig.me i gästen mot curl.exe -4 -s https://ifconfig.me på värden. Olika adresser betyder att gästen äger tunneln, och en värd på VPN med en gäst som visar hemmets leverantör är fallet där ingenting ärvdes.
4. Upprepa båda med -6. En tunnel med bara v4 läcker v6 om inte klienten blockerar eller routar det, och många klienter lämnar v6 på det fysiska gränssnittet som standard.

För en design med värdgateway, där flera gäster delar en tunnel, måste värden vidarebefordra och översätta. På en Linux-värd är det tre delar, och gästen faller tyst tillbaka på sin vanliga rutt när någon av dem saknas:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

På WireGuard-sidan måste värdpartnerns AllowedIPs innehålla gästsubnätet, till exempel 192.168.122.0/24, annars kommer returpaketen aldrig fram och uppsättningen ser ut som ett brandväggsproblem. En Windows-värd når samma resultat med Internet Connection Sharing eller en NAT-regel på Hyper-V-växeln och behöver samma kontroll av returvägen.

När layouten fortfarande är öppen täcker den här tabellen de vanligaste arrangemangen:

Två tunnlar, två gäster och konflikterna mellan dem

När du behöver två utgångar samtidigt är mönstret som håller en tunnel per gäst. Varje VM behåller sin egen standardrutt och resolver, värden stannar på det vanliga nätverket, och de två tunnlarna bråkar aldrig om samma routingtabell. Att brygga två gäster samman slår inte heller ihop deras rutter: det virtuella nätverket ger en väg, och varje klient måste fortfarande få veta att denna lokala trafik får gå förbi tunneln.

Att köra en värdtunnel och en gästtunnel tillsammans är legitimt, och medveten nästning är ibland precis vad du vill ha, där gästen går ut genom sin egen tunnel och den tunneln går ut genom värdens. Det som gör det till ett avbrott är att ingen skrev ner vilken ändpunkt som ska nås genom vilket lager. Håll en lista med två kolumner över destination och ägare, och en ruttkonflikt blir en uppslagning i stället för en eftermiddag av upptäckter.

Verifiera och lämna sedan återställningen hos ägaren

Testa inifrån gästen med en färsk applikationsprocess: trafik, namnmatchning, båda adressfamiljerna och vad som händer när tunneln faller. Värdens VPN-ikon säger ingenting om gästens täckning, och det är den vanligaste falska bekräftelsen i hela det här området.

Återställningen hör också till ägaren. En gästägd tunnel återställs av gästens egen klient och de rutter den skrev. En värdägd design återställs av värdens startsekvens, och vidarebefordringsreglerna överlever inte en omstart om inte en unit eller en startuppgift tillämpar dem igen. En återställd ögonblicksbild är en utrullning, inte en ångring, eftersom den tar tillbaka gamla uppgifter och gamla rutter tillsammans med disken. Innan du kallar arbetet klart, bekräfta att ägaren fortfarande stämmer med raden du skrev, att DNS och båda adressfamiljerna löses inuti gästen, att en död tunnel lämnar ett användbart nätverk i stället för ett svart hål, och att en omstart eller återställning av ögonblicksbild återskapar samma tillstånd.