Kjøre VPN på verten eller inne i VM-en? Beslutningsveiledning

Å bygge tunnelen inne i gjesten og å bygge den på verten endrer begge adressen en nettleser rapporterer, og der slutter likheten. En gjesteeid tunnel beholder nøklene sine, standardruten sin og resolveren sin inne i gjestekjernen, mens verten videresender krypterte pakker til én ekstern adresse. En verteid tunnel er speilbildet: vertsklienten holder sesjonen og anvender ruter og policy, og gjesten låner det som kommer ut. Velger du feil eier, sender hvert senere symptom deg til feil maskin. To kommandoer avgjør spørsmålet på rundt et minutt, og resten av denne veiledningen er hva du gjør med svaret.

Avgjør eieren før du rører klienten

Regelen handler om hvor chifferteksten produseres, ikke om hvilken maskin som viser et VPN-ikon. Hvis gjesten produserer den, trenger gjesten en fungerende rute til VPN-serveren og ingenting annet fra verten. Hvis verten produserer den, må gjestens vei gjennom verten overleve den policyen vertsklienten pålegger lokal trafikk.

Tre spørsmål velger som regel plasseringen for deg. Må gjestens trafikk overleve en bedriftsklient på verten? Da hører tunnelen hjemme i gjesten. Trenger flere gjester én legitimasjon og én utgangsadresse? Da hører den hjemme på verten, med videresending satt opp med vilje. Skal gjestens trafikk holdes helt utenfor vertens VPN? Da er en gjestetunnel den eneste ordningen som gir deg det per konstruksjon.

Skriv svaret som én linje ved siden av VM-navnet: guest-owned eller host-owned. I et laboratorium med seks maskiner sparer den noten mer tid enn noe trinn nedenfor, fordi den hindrer deg i å feilsøke en tunnel som aldri var i maskinen du er logget inn på.

WSL1 og WSL2 er motsatte tilfeller

WSL1 er ikke en virtuell maskin, så plasseringsspørsmålet fordamper stort sett. Dens Linux-binærfiler kjører mot Windows' nettverksstakk gjennom et oversettelseslag, og en Linux-VPN-klient har ingen uavhengige grensesnitt å konfigurere. Det som virker, er en tunnel på Windows-siden, der distribusjonen bruker resultatet uten å eie noe.

WSL2 er det motsatte. Det kjører en ekte kjerne i en lett hjelpe-VM bak en virtuell Hyper-V-svitsj, og adresserommet NAT-es gjennom en adapter på vertssiden. En Linux-klient inne i distribusjonen oppfører seg derfor som på en fysisk Linux-boks: den lager tun0 eller wg0, installerer sine egne ruter og virker. Feilen bor på vertssiden. Når en Windows-VPN-klient kobler til med en policy som blokkerer trafikk på lokale nettverk, behandler den WSL2-subnettet som et ubetrodd lokalt nettverk og kutter NAT-veien. Distribusjonen mister da DNS og utgående tilgang mens dens egen tunnel fortsatt er sunn: wg show rapporterer håndtrykk, ip route ser riktig ut, og curl henger.

Hvilken rettelse du kan bruke avhenger av Windows-bygget. Den eldre er et unntak i vertsklienten for WSL-subnettet, lagt til under klientens innstillinger for lokalt nettverk eller delt tunnel. Den nyere, på Windows 11-bygg som støtter det, er speilet nettverk: sett networkingMode=mirrored i [wsl2]-delen av %UserProfile%\.wslconfig, kjør wsl --shutdown, og distribusjonen deler vertens grensesnitt i stedet for et privat NAT-subnett. Speilet modus endrer også hvordan localhost og innkommende porter oppfører seg, så behandle det som en migrering og ikke som en bryter.

NAT, bro og hva verten kan se

Under NAT adresseres gjestens tunnelpakker til VPN-serverens offentlige adresse og forlater vertsadapteren som kryptert UDP eller TCP. Verten ser én strøm og dens byttall, ingenting om destinasjonene inni. Under en broet adapter har gjesten sin egen identitet på lag 2 på det fysiske LAN-et, tar sin egen DHCP-lease og ser for enhver MAC-basert policy ut som en ekstra enhet. Ingen av modusene lar verten lese tunnelens nyttelast; den broede gjesten er bare langt mer synlig for nettverket rundt seg.

Isolasjonen har også en nedre grense. En gjest kan ikke skjule seg for maskinen som eier minnet dens, og den som kontrollerer verten kan lese nøkler ut av gjestens RAM. Det en gjestetunnel gir deg, er en rute- og malware-grense, ikke beskyttelse mot personen som holder på den bærbare. De dokumenterte adaptermodusene er verdt å ha åpne mens du velger, siden modusen endrer både det verten ser og det LAN-et ser.

Veiledning: plasser den, konfigurer den, bevis det

Kjør disse fire sjekkene i rekkefølge i et ferskt gjesteskall, og stopp ved den første som ikke stemmer med eieren du skrev ned.

1. ip route get 1.1.1.1 som returnerer tun0 eller wg0 betyr gjesteeid; eth0 med et privat neste hopp betyr verteid.
2. resolvectl query example.com, eller les /etc/resolv.conf der gjesten ikke kjører noen resolvertjeneste. En tunnel som bærer trafikk men ikke DNS, er den vanligste halvkonfigurerte tilstanden.
3. Sammenlign utgangene: curl -4 -s https://ifconfig.me i gjesten mot curl.exe -4 -s https://ifconfig.me på verten. Ulike adresser betyr at gjesten eier tunnelen, og en vert på VPN med en gjest som viser hjemmets leverandør er tilfellet der ingenting ble arvet.
4. Gjenta begge med -6. En tunnel med bare v4 lekker v6 med mindre klienten blokkerer eller ruter det, og mange klienter lar v6 bli på den fysiske grensesnittet som standard.

For et design med vertsgateway, der flere gjester deler én tunnel, må verten videresende og oversette. På en Linux-vert er det tre deler, og gjesten faller stille tilbake til sin vanlige rute når en av 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 må vertspartnerens AllowedIPs inneholde gjeste-subnettet, for eksempel 192.168.122.0/24, ellers kommer returpakkene aldri frem og oppsettet ser ut som et brannmurproblem. En Windows-vert når samme resultat med Internet Connection Sharing eller en NAT-regel på Hyper-V-svitsjen og trenger samme kontroll av returveien.

Når oppsettet ennå er åpent, dekker denne tabellen de vanligste ordningene:

To tunneler, to gjester og konfliktene mellom dem

Når du trenger to utganger samtidig, er mønsteret som holder, én tunnel per gjest. Hver VM beholder sin egen standardrute og resolver, verten blir på det vanlige nettverket, og de to tunnelene krangler aldri om samme rutetabell. Å bro to gjester sammen slår heller ikke sammen rutene deres: det virtuelle nettverket gir en vei, og hver klient må fortsatt få vite at denne lokale trafikken kan gå utenom tunnelen.

Å kjøre en vertstunnel og en gjestetunnel sammen er legitimt, og bevisst nesting er noen ganger akkurat det du vil ha, med gjesten som går ut gjennom sin egen tunnel og den tunnelen som går ut gjennom vertens. Det som gjør det til en avbrudd, er at ingen skrev ned hvilket endepunkt som skal nås gjennom hvilket lag. Hold en to-kolonne liste over destinasjon og eier, og en rutekonflikt blir et oppslag i stedet for en ettermiddag med oppdagelse.

Verifiser, og la deretter gjenopprettingen bli hos eieren

Test inne fra gjesten med en fersk applikasjonsprosess: trafikk, navneoppslag, begge adressefamilier og hva som skjer når tunnelen faller. Vertens VPN-ikon sier ingenting om gjestens dekning, og det er den vanligste falske bekreftelsen i hele dette området.

Gjenoppretting hører også til eieren. En gjesteeid tunnel gjenopprettes av gjestens egen klient og rutene den skrev. Et verteid design gjenopprettes av vertens oppstartssekvens, og videresendingsreglene overlever ikke en omstart med mindre en unit eller en oppstartsoppgave anvender dem igjen. Et gjenopprettet øyeblikksbilde er en utrulling, ikke en angring, fordi det bringer gamle legitimasjoner og gamle ruter tilbake sammen med disken. Før du kaller arbeidet ferdig, bekreft at eieren fortsatt samsvarer med linjen du skrev, at DNS og begge adressefamilier løses inne i gjesten, at en død tunnel etterlater et brukbart nettverk i stedet for et svart hull, og at en omstart eller gjenoppretting av øyeblikksbilde gjenskaper samme tilstand.