Ajetaanko VPN isännässä vai VM:n sisällä? Päätösohje

Tunnelin rakentaminen vieraan sisälle ja sen rakentaminen isäntään muuttavat molemmat osoitetta, jonka selain raportoi, ja siihen yhtäläisyys loppuu. Vieraan omistama tunneli pitää avaimensa, oletusreittinsä ja resolverinsa vieraan ytimessä, kun taas isäntä välittää salatut paketit yhteen etäosoitteeseen. Isännän omistama tunneli on peilikuva: isännän asiakas pitää istunnon ja soveltaa reittejä ja käytäntöä, ja vieras lainaa sen, mikä tulee ulos. Valitse väärä omistaja, ja jokainen myöhempi oire lähettää sinut väärälle koneelle. Kaksi komentoa ratkaisee kysymyksen noin minuutissa, ja loput tästä ohjeesta on, mitä vastauksella tehdään.

Päätä omistaja ennen kuin kosket asiakkaaseen

Sääntö koskee sitä, missä salateksti tuotetaan, ei sitä, mikä kone näyttää VPN-kuvaketta. Jos vieras tuottaa sen, vieras tarvitsee toimivan reitin VPN-palvelimeen eikä mitään muuta isännältä. Jos isäntä tuottaa sen, vieraan on selvittävä isännän kautta kulkevasta polusta riippumatta siitä käytännöstä, jonka isännän asiakas asettaa paikalliselle liikenteelle.

Kolme kysymystä valitsee sijoituksen yleensä puolestasi. Täytyykö vieraan liikenteen selvitä isännän yritysasiakkaasta? Silloin tunneli kuuluu vieraaseen. Tarvitsevatko useat vieraat yhden tunnistetiedon ja yhden lähtöosoitteen? Silloin se kuuluu isäntään, välitys tarkoituksella asetettuna. Pitääkö vieraan liikenteen pysyä kokonaan isännän VPN:n ulkopuolella? Silloin vieraan tunneli on ainoa järjestely, joka antaa sen rakenteellisesti.

Kirjoita vastaus yhdelle riville VM:n nimen viereen: guest-owned tai host-owned. Kuuden koneen laboratoriossa se merkintä säästää enemmän aikaa kuin mikään alla oleva vaihe, koska se estää sinua vianmäärityksessä tunnelista, joka ei koskaan ollut siinä koneessa, johon kirjauduit.

WSL1 ja WSL2 ovat vastakkaisia tapauksia

WSL1 ei ole virtuaalikone, joten sijoituskysymys suurelta osin haihtuu. Sen Linux-binäärit ajetaan Windowsin verkkopinon päällä käännöskerroksen kautta, eikä Linux-VPN-asiakkaalla ole itsenäisiä liitäntöjä määritettäväksi. Toimiva järjestely on Windowsin puolella oleva tunneli, jossa jakelu käyttää tulosta omistamatta mitään.

WSL2 on päinvastoin. Se ajaa oikeaa ydintä kevyessä apu-VM:ssä Hyper-V-virtuaalikytkimen takana, ja sen osoiteavaruus NAT:ataan isännän puolen sovittimen kautta. Siksi jakelun sisällä oleva Linux-asiakas käyttäytyy kuin fyysisellä Linux-koneella: se luo tun0 tai wg0, asentaa omat reittinsä ja toimii. Vika asuu isännän puolella. Kun Windows-VPN-asiakas yhdistää käytännöllä, joka estää liikennettä paikallisverkoissa, se kohtelee WSL2:n aliverkkoa epäluotettavana paikallisverkkona ja katkaisee NAT-polun. Silloin jakelu menettää DNS:n ja lähtevän yhteyden, vaikka sen oma tunneli on yhä terve: wg show raportoi kättelyn, ip route näyttää oikealta ja curl jumittuu.

Mitä korjausta voit käyttää, riippuu Windowsin koontiversiosta. Vanhempi on isännän asiakkaassa oleva WSL-aliverkon poikkeus, joka lisätään asiakkaan paikallisverkon tai jaetun tunnelin asetuksiin. Uudempi, sitä tukevissa Windows 11 -koontiversioissa, on peilattu verkkoliikenne: laita networkingMode=mirrored %UserProfile%\.wslconfig-tiedoston [wsl2]-osioon, aja wsl --shutdown, ja jakelu jakaa isännän liitännät yksityisen NAT-aliverkon sijaan. Peilattu tila muuttaa myös localhostin ja saapuvien porttien käyttäytymistä, joten käsittele sitä siirtymänä, älä kytkimenä.

NAT, silta ja mitä isäntä voi nähdä

NAT:n alla vieraan tunnelipaketit osoitetaan VPN-palvelimen julkiseen osoitteeseen ja ne lähtevät isännän sovittimen kautta salattuna UDP:nä tai TCP:nä. Isäntä näkee yhden virtauksen ja sen tavumäärän, ei mitään sen sisällä olevista kohteista. Siltasovittimen alla vieraalla on oma 2-kerroksen identiteettinsä fyysisessä LAN-verkossa, se ottaa oman DHCP-vuokransa ja näyttää MAC-pohjaiselle käytännölle toiselta laitteelta. Kumpikaan tila ei anna isännän lukea tunnelin hyötykuormaa; sillattu vieras on yksinkertaisesti paljon näkyvämpi ympäröivälle verkolle.

Eristyksellä on myös alaraja. Vieras ei voi piiloutua koneelta, joka omistaa sen muistin, ja kuka tahansa isäntää hallitseva voi lukea avaimia vieraan RAM-muistista. Vieraan tunneli antaa sinulle reititysrajan ja haittaohjelmarajan, ei suojaa kannettavaa pitävältä henkilöltä. Dokumentoidut sovitintilat kannattaa pitää auki valinnan aikana, koska tila muuttaa sekä sitä, mitä isäntä näkee, että sitä, mitä LAN näkee.

Ohje: sijoita, määritä, todista

Aja nämä neljä tarkistusta järjestyksessä tuoreessa vieraan kuoressa ja pysähdy ensimmäiseen, joka on ristiriidassa kirjoittamasi omistajan kanssa.

1. ip route get 1.1.1.1, joka palauttaa tun0 tai wg0, tarkoittaa vieraan omistusta, ja eth0 yksityisellä seuraavalla hypyllä tarkoittaa isännän omistusta.
2. resolvectl query example.com, tai lue /etc/resolv.conf siellä, missä vieras ei aja resolver-palvelua. Tunneli, joka kuljettaa liikennettä mutta ei DNS:ää, on yleisin puoliksi määritetty tila.
3. Vertaa lähtöjä: curl -4 -s https://ifconfig.me vieraassa vastaan curl.exe -4 -s https://ifconfig.me isännässä. Eri osoitteet tarkoittavat, että vieras omistaa tunnelin, ja isäntä VPN:ssä vieraan näyttäessä kodin operaattorin on tapaus, jossa mitään ei peritty.
4. Toista molemmat -6:lla. Vain v4:n tunneli vuotaa v6:ta, ellei asiakas estä tai reititä sitä, ja monet asiakkaat jättävät v6:n fyysiselle liitännälle oletuksena.

Isännän yhdyskäytäväratkaisussa, jossa useat vieraat jakavat yhden tunnelin, isännän on välitettävä ja käännettävä. Linux-isännässä se on kolme osaa, ja vieras putoaa hiljaa tavalliselle reitilleen, kun jokin niistä puuttuu:

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

WireGuardin puolella isännän vastapuolen AllowedIPs:n on sisällettävä vieraiden aliverkko, esimerkiksi 192.168.122.0/24, muuten paluupaketit eivät koskaan tule perille ja asetelma näyttää palomuuriongelmalta. Windows-isäntä pääsee samaan tulokseen Internet Connection Sharingilla tai Hyper-V-kytkimen NAT-säännöllä ja tarvitsee saman paluupolun tarkistuksen.

Kun asetelma on vielä avoin, tämä taulukko kattaa yleisimmät järjestelyt:

Kaksi tunnelia, kaksi vierasta ja niiden väliset ristiriidat

Kun tarvitset kaksi lähtöä yhtä aikaa, kestävä malli on yksi tunneli vierasta kohti. Jokainen VM pitää oman oletusreittinsä ja resolverinsa, isäntä pysyy tavallisessa verkossa eivätkä kaksi tunnelia riitele koskaan samasta reititystaulusta. Kahden vieraan sillottaminen ei sekään yhdistä niiden reittejä: virtuaaliverkko tarjoaa polun, ja jokaiselle asiakkaalle on yhä kerrottava, että tämä paikallinen liikenne saa ohittaa tunnelin.

Isännän tunnelin ja vieraan tunnelin ajaminen yhdessä on laillista, ja tarkoituksellinen sisäkkäisyys on joskus juuri sitä, mitä haluat, kun vieras lähtee omasta tunnelistaan ja se tunneli lähtee isännän tunnelista. Sen tekee katkokseksi se, ettei kukaan kirjoittanut muistiin, mikä päätepiste saavutetaan minkä kerroksen kautta. Pidä kaksisarakkeista listaa kohteesta ja omistajasta, ja reittiristiriidasta tulee hakeminen kokonaisen löytöiltapäivän sijaan.

Vahvista ja jätä palautus omistajalle

Testaa vieraan sisältä tuoreella sovellusprosessilla: liikenne, nimien selvitys, molemmat osoiteperheet ja mitä tapahtuu, kun tunneli putoaa. Isännän VPN-kuvake ei kerro mitään vieraan kattavuudesta, ja se on yleisin väärä vahvistus koko tällä alueella.

Palautus kuuluu myös omistajalle. Vieraan omistama tunneli palautetaan vieraan omalla asiakkaalla ja sen kirjoittamilla reiteillä. Isännän omistama ratkaisu palautetaan isännän käynnistysjärjestyksellä, eivätkä välityssäännöt selviä uudelleenkäynnistyksestä, ellei unit tai käynnistystehtävä ota niitä uudelleen käyttöön. Palautettu tilannevedos on käyttöönotto, ei kumoaminen, koska se tuo vanhat tunnistetiedot ja vanhat reitit takaisin levyn mukana. Ennen kuin kutsut työn valmiiksi, vahvista, että omistaja vastaa yhä kirjoittamaasi riviä, että DNS ja molemmat osoiteperheet selvitetään vieraan sisällä, että kuollut tunneli jättää käyttökelpoisen verkon mustan aukon sijaan ja että uudelleenkäynnistys tai tilannevedoksen palautus tuottaa saman tilan.