Køyre VPN på verten eller inne i VM-en? Avgjerdsrettleiiing

Å byggje tunnelen inne i gjesten og å byggje han på verten endrar begge adressa ein nettlesar rapporterer, og der sluttar likskapen. Ein gjesteeigd tunnel held på nøklane sine, standardruta si og oppløysaren sin inne i gjestekjernen, medan verten sender krypterte pakkar til éi fjernadresse. Ein verteigd tunnel er spegelbiletet: vertsklienten held på økta og brukar ruter og policy, og gjesten låner det som kjem ut. Vel du feil eigar, sender kvart seinare symptom deg til feil maskin. To kommandoar avgjer spørsmålet på rundt eitt minutt, og resten av denne rettleiinga er kva du gjer med svaret.

Avgjer eigaren før du rører klienten

Regelen handlar om kvar sifferteksten blir produsert, ikkje om kva maskin som viser eit VPN-ikon. Viss gjesten produserer han, treng gjesten ei fungerande rute til VPN-tenaren og ingenting anna frå verten. Viss verten produserer han, må vegen til gjesten gjennom verten overleve den policyen vertsklienten legg på lokal trafikk.

Tre spørsmål vel som regel plasseringa for deg. Må trafikken til gjesten overleve ein bedriftsklient på verten? Då høyrer tunnelen heime i gjesten. Treng fleire gjester éi legitimasjon og éi utgangsadresse? Då høyrer han heime på verten, med vidaresending sett opp med vilje. Skal trafikken til gjesten haldast heilt utanfor VPN-en til verten? Då er ein gjestetunnel den einaste ordninga som gjev deg det av konstruksjonen.

Skriv svaret som éi linje ved sida av VM-namnet: guest-owned eller host-owned. I eit laboratorium med seks maskinar sparar den notata meir tid enn noko steg nedanfor, fordi ho hindrar deg i å feilsøkje ein tunnel som aldri var i maskina du er innlogga på.

WSL1 og WSL2 er motsette tilfelle

WSL1 er ikkje ei virtuell maskin, så plasseringsspørsmålet fordampar stort sett. Linux-binærfilene hans køyrer mot nettverksstakken til Windows gjennom eit omsetjingslag, og ein Linux-VPN-klient har ingen uavhengige grensesnitt å konfigurere. Det som verkar, er ein tunnel på Windows-sida, der distribusjonen brukar resultatet utan å eige noko.

WSL2 er det motsette. Det køyrer ein ekte kjerne i ein lett hjelpe-VM bak ein virtuell Hyper-V-brytar, og adresserommet blir NAT-omsett gjennom ein adapter på vertssida. Ein Linux-klient inne i distribusjonen oppfører seg difor som på ein fysisk Linux-boks: han lagar tun0 eller wg0, installerer sine eigne ruter og verkar. Feilen bur på vertssida. Når ein Windows-VPN-klient koplar til med ein policy som blokkerer trafikk på lokale nettverk, handsamar han WSL2-subnettet som eit lite påliteleg lokalt nettverk og kuttar NAT-vegen. Distribusjonen misser då DNS og utgåande tilgang medan tunnelen hans sjølv framleis er sunn: wg show rapporterer handtrykk, ip route ser rett ut, og curl heng.

Kva retting du kan bruke, kjem an på Windows-bygget. Den eldre er eit unntak i vertsklienten for WSL-subnettet, lagt til under innstillingane til klienten for lokalt nettverk eller delt tunnel. Den nyare, på Windows 11-bygg som støttar det, er spegla nettverk: set networkingMode=mirrored i [wsl2]-delen av %UserProfile%\.wslconfig, køyr wsl --shutdown, og distribusjonen deler grensesnitta til verten i staden for eit privat NAT-subnett. Spegla modus endrar òg korleis localhost og innkommande portar oppfører seg, så handsam han som ein migrasjon og ikkje som ein brytar.

NAT, bru og kva verten kan sjå

Under NAT blir tunnelpakkane til gjesten adresserte til den offentlege adressa til VPN-tenaren og går ut gjennom vertsadapteren som kryptert UDP eller TCP. Verten ser éin straum og byttalet hans, ingenting om måla inni. Under ein brua adapter har gjesten sin eigen identitet på lag 2 på det fysiske LAN-et, tek sin eigen DHCP-leige og ser for ein kvar MAC-basert policy ut som ein ekstra eining. Ingen av modusane lèt verten lese nyttelasta i tunnelen; den brua gjesten er berre langt meir synleg for nettverket rundt seg.

Isolasjonen har òg ei nedre grense. Ein gjest kan ikkje gøyme seg for maskina som eig minnet hans, og den som styrer verten kan lese nøklar ut av RAM-en til gjesten. Det ein gjestetunnel gjev deg, er ei rute- og malware-grense, ikkje vern mot personen som held på den bereelege. Dei dokumenterte adaptermodusane er verd å ha opne medan du vel, sidan modusen endrar både det verten ser og det LAN-et ser.

Rettleiing: plasser han, konfigurer han, prov han

Køyr desse fire sjekkane i rekkjefølgje i eit ferskt gjestescal, og stopp ved den første som ikkje stemmer med eigaren du skreiv ned.

1. ip route get 1.1.1.1 som returnerer tun0 eller wg0 tyder gjesteeigd, og eth0 med eit privat neste hopp tyder verteigd.
2. resolvectl query example.com, eller les /etc/resolv.conf der gjesten ikkje køyrer noka oppløysarteneste. Ein tunnel som ber trafikk men ikkje DNS, er den vanlegaste halvkonfigurerte tilstanden.
3. Samanlikn utgangane: curl -4 -s https://ifconfig.me i gjesten mot curl.exe -4 -s https://ifconfig.me på verten. Ulike adresser tyder at gjesten eig tunnelen, og ein vert på VPN med ein gjest som viser heimeleverandøren er tilfellet der ingenting vart arva.
4. Gjenta begge med -6. Ein tunnel med berre v4 lekk v6 med mindre klienten blokkerer eller ruter det, og mange klientar lèt v6 bli på den fysiske grensesnitta som standard.

For eit design med vertsportal, der fleire gjester deler éin tunnel, må verten vidaresende og omsetje. På ein Linux-vert er det tre delar, og gjesten fell stille tilbake til den vanlege ruta si når ein av dei manglar:

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-sida må AllowedIPs til vertspartnaren innehalde gjeste-subnettet, til dømes 192.168.122.0/24, elles kjem returpakkane aldri fram og oppsettet ser ut som eit brannmurproblem. Ein Windows-vert når same resultat med Internet Connection Sharing eller ei NAT-regel på Hyper-V-brytaren og treng same kontrollen av returvegen.

Når oppsettet enno er ope, dekkjer denne tabellen dei vanlegaste ordningane:

To tunnelar, to gjester og konfliktane mellom dei

Når du treng to utgangar samstundes, er mønsteret som held, éin tunnel per gjest. Kvar VM held på si eiga standardrute og oppløysar, verten blir på det vanlege nettverket, og dei to tunnelane kranglar aldri om same rutetabell. Å bru to gjester saman slår heller ikkje saman rutene deira: det virtuelle nettverket gjev ein veg, og kvar klient må framleis få vite at denne lokale trafikken kan gå utanom tunnelen.

Å køyre ein vertstunnel og ein gjestetunnel saman er legitimt, og medvite nesting er stundom nettopp det du vil ha, med gjesten som går ut gjennom sin eigen tunnel og den tunnelen som går ut gjennom verten sin. Det som gjer det til eit avbrot, er at ingen skreiv ned kva endepunkt som skal nåast gjennom kva lag. Hald ei liste med to kolonnar over mål og eigar, og ein rutekonflikt blir eit oppslag i staden for ein ettermiddag med oppdaging.

Stadfest, og la deretter gjenopprettinga bli hjå eigaren

Test inne frå gjesten med ein fersk applikasjonsprosess: trafikk, namneoppslag, begge adressefamiliane og kva som skjer når tunnelen fell. VPN-ikonet til verten seier ingenting om dekkjinga til gjesten, og det er den vanlegaste falske stadfestinga i heile dette området.

Gjenoppretting høyrer òg til eigaren. Ein gjesteeigd tunnel blir gjenoppretta av eigen klient til gjesten og rutene han skreiv. Eit verteigd design blir gjenoppretta av oppstartssekvensen til verten, og vidaresendingsreglane overlever ikkje ein omstart med mindre ein unit eller ein oppstartsoppgåve legg dei på igjen. Eit gjenoppretta augneblinksbilete er ein utrulling, ikkje ein angring, fordi det bringar gamle legitimasjonar og gamle ruter tilbake saman med disken. Før du kallar arbeidet ferdig, stadfest at eigaren framleis svarar til linja du skreiv, at DNS og begge adressefamiliane blir løyste inne i gjesten, at ein daud tunnel lèt att eit brukbart nettverk i staden for eit svart hol, og at ein omstart eller gjenoppretting av augneblinksbilete gjev same tilstand.