Kør VPN på værten eller inde i VM'en? Beslutningsmanual

At bygge tunnelen inde i gæsten og at bygge den på værten ændrer begge den adresse, en browser rapporterer, og det er der, ligheden slutter. En gæsteejet tunnel holder sine nøgler, sin standardrute og sin resolver inde i gæstens kerne, mens værten videresender krypterede pakker til én fjernadresse. En værtejet tunnel er det spejlvendte billede: værtsklienten holder sessionen og anvender ruter og politik, og gæsten låner, hvad der kommer ud. Vælger du den forkerte ejer, sender hvert senere symptom dig til den forkerte maskine. To kommandoer afgør spørgsmålet på omkring et minut, og resten af denne manual er, hvad du gør med svaret.

Afgør ejerskabet, før du rører klienten

Reglen handler om, hvor chifferteksten produceres, ikke om hvilken maskine der viser et VPN-ikon. Hvis gæsten producerer den, har gæsten brug for en fungerende rute til VPN-serveren og intet andet fra værten. Hvis værten producerer den, skal gæstens vej gennem værten overleve den politik, værtsklienten pålægger lokal trafik.

Tre spørgsmål vælger som regel placeringen for dig. Skal gæstens trafik overleve en virksomhedsklient på værten? Så hører tunnelen til i gæsten. Skal flere gæster dele én legitimationsoplysning og én udgangsadresse? Så hører den til på værten, med videresendelse sat op med vilje. Skal gæstens trafik holdes helt uden for værtens VPN? Så er en gæstetunnel den eneste ordning, der giver dig det per konstruktion.

Skriv svaret ned som én linje ved siden af VM-navnet: guest-owned eller host-owned. I et laboratorium med seks maskiner sparer den note mere tid end noget skridt nedenfor, fordi den forhindrer dig i at fejlfinde en tunnel, der aldrig var i den maskine, du er logget ind på.

WSL1 og WSL2 er modsatte tilfælde

WSL1 er ikke en virtuel maskine, så placeringsspørgsmålet fordamper for det meste. Dets Linux-binære kører mod Windows' netværksstak gennem et oversættelseslag, og en Linux-VPN-klient har ingen uafhængige grænseflader at konfigurere. Den ordning, der virker, er en tunnel på Windows-siden, hvor distributionen bruger resultatet uden at eje noget.

WSL2 er det modsatte. Den kører en rigtig kerne i en let hjælpe-VM bag en virtuel Hyper-V-switch, og dens adresserum NAT'es gennem en adapter på værtsiden. En Linux-klient inde i distributionen opfører sig derfor, som den ville på en fysisk Linux-boks: den opretter tun0 eller wg0, installerer sine egne ruter og virker. Fejlen bor på værtsiden. Når en Windows-VPN-klient forbinder med en politik, der blokerer trafik på lokale netværk, behandler den WSL2-undernettet som et utroværdigt lokalt netværk og skærer NAT-stien over. Distributionen mister så DNS og udgående adgang, mens dens egen tunnel stadig er sund: wg show rapporterer et handshake, ip route ser korrekt ud, og curl hænger.

Hvilken løsning du kan bruge afhænger af Windows-builden. Den ældre er en undtagelse i værtsklienten for WSL-undernettet, tilføjet under klientens indstillinger for lokalt netværk eller delt tunnel. Den nyere, på Windows 11-builds der understøtter det, er spejlet netværk: sæt networkingMode=mirrored i [wsl2]-afsnittet af %UserProfile%\.wslconfig, kør wsl --shutdown, og distributionen deler værtens grænseflader i stedet for et privat NAT-undernet. Spejlet tilstand ændrer også, hvordan localhost og indgående porte opfører sig, så behandl det som en migrering frem for en kontakt.

NAT, bro og hvad værten kan se

Under NAT adresseres gæstens tunnelpakker til VPN-serverens offentlige adresse og forlader værtsadapteren som krypteret UDP eller TCP. Værten ser én strøm og dens bytetal, intet om destinationerne indeni. Under en broet adapter har gæsten sin egen identitet på lag 2 på det fysiske LAN, tager sin egen DHCP-lease og ser for enhver MAC-baseret politik ud som en ekstra enhed. Ingen af tilstandene lader værten læse tunnelens nyttelast; den broede gæst er blot langt mere synlig for netværket omkring den.

Der er også en bundgrænse for isoleringen. En gæst kan ikke skjule sig for den maskine, der ejer dens hukommelse, og den, der styrer værten, kan læse nøgler ud af gæstens RAM. Det, en gæstetunnel giver dig, er en rute- og malware-grænse, ikke beskyttelse mod personen, der holder på bærbaren. De dokumenterede adaptertilstande er værd at have åbne, mens du vælger, da tilstanden ændrer både, hvad værten ser, og hvad LAN'et ser.

Manual: placér den, konfigurer den, bevis det

Kør disse fire tjek i rækkefølge i en frisk gæsteskal, og stop ved det første, der ikke stemmer med den ejer, du skrev ned.

1. ip route get 1.1.1.1 der returnerer tun0 eller wg0 betyder gæsteejet; eth0 med et privat næste hop betyder værtejet.
2. resolvectl query example.com, eller læs /etc/resolv.conf hvor gæsten ikke kører nogen resolvertjeneste. En tunnel, der bærer trafik men ikke DNS, er den mest almindelige halvkonfigurerede tilstand.
3. Sammenlign udgange: curl -4 -s https://ifconfig.me i gæsten mod curl.exe -4 -s https://ifconfig.me på værten. Forskellige adresser betyder, at gæsten ejer tunnelen, og en vært på VPN med en gæst, der viser hjemmets udbyder, er tilfældet, hvor intet blev arvet.
4. Gentag begge med -6. En tunnel med kun v4 lækker v6, medmindre klienten blokerer eller ruter den, og mange klienter lader v6 blive på den fysiske grænseflade som standard.

Til et design med værtsgateway, hvor flere gæster deler én tunnel, skal værten videresende og oversætte. På en Linux-vært er det tre dele, og gæsten falder stille tilbage til sin almindelige rute, når en af dem mangler:

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-siden skal værtspartnerens AllowedIPs indeholde gæsteundernettet, for eksempel 192.168.122.0/24, ellers ankommer returpakkerne aldrig, og opsætningen ligner et firewallproblem. En Windows-vært når samme resultat med Internet Connection Sharing eller en NAT-regel på Hyper-V-switchen og har brug for samme kontrol af returvejen.

Når layoutet stadig er åbent, dækker denne tabel de ordninger, der oftest kommer op:

To tunneler, to gæster og konflikterne mellem dem

Når du har brug for to udgange på én gang, er det mønster, der holder, én tunnel pr. gæst. Hver VM beholder sin egen standardrute og resolver, værten bliver på det almindelige netværk, og de to tunneler skændes aldrig om den samme rutetabel. At bro to gæster sammen slår heller ikke deres ruter sammen: det virtuelle netværk giver en vej, og hver klient skal stadig have at vide, at denne lokale trafik må gå uden om tunnelen.

At køre en værtstunnel og en gæstetunnel sammen er legitimt, og bevidst indlejring er nogle gange præcis, hvad du vil have, med gæsten der går ud gennem sin egen tunnel, og den tunnel der går ud gennem værtens. Det, der gør det til en afbrydelse, er, at ingen skrev ned, hvilket endepunkt der skal nås gennem hvilket lag. Hold en to-kolonne liste over destination og ejer, og en rutekonflikt bliver et opslag i stedet for en eftermiddag med opdagelse.

Verificér, og behold derefter genopretning hos ejeren

Test inde fra gæsten med en frisk applikationsproces: trafik, navneopløsning, begge adressefamilier og hvad der sker, når tunnelen falder. Værtens VPN-ikon siger intet om gæstens dækning, og det er den mest almindelige falske bekræftelse i hele dette område.

Genopretning hører også til ejeren. En gæsteejet tunnel gendannes af gæstens egen klient og de ruter, den skrev. Et værtejet design gendannes af værtens opstartssekvens, og videresendelsesreglerne overlever ikke en genstart, medmindre en unit eller en opstartsopgave anvender dem igen. Et gendannet snapshot er en udrulning, ikke en fortrydelse, fordi det bringer gamle legitimationsoplysninger og gamle ruter tilbage sammen med disken. Før du kalder arbejdet færdigt, skal du bekræfte, at ejeren stadig svarer til den linje, du skrev, at DNS og begge adressefamilier opløses inde i gæsten, at en død tunnel efterlader et brugbart netværk i stedet for et sort hul, og at en genstart eller snapshotgendannelse giver samme tilstand.