VPN hoste ar VM viduje? Sprendimo vadovas

Tunelį kurti svečio viduje ir kurti jį hoste abiem atvejais keičiamas adresas, kurį praneša naršyklė, ir čia panašumas baigiasi. Svečio valdomas tunelis savo raktus, numatytąjį maršrutą ir resolverį laiko svečio branduolyje, o hostas persiunčia šifruotus paketus vienu atstumu nutolusiu adresu. Hoste valdomas tunelis yra veidrodinė kopija: hosto klientas laiko sesiją ir taiko maršrutus bei politiką, o svečias skolinasi tai, kas išeina. Pasirinkę netinkamą savininką, kiekvienas vėlesnis simptomas nukreips jus į netinkamą mašiną. Dvi komandos išsprendžia klausimą maždaug per minutę, o likusi šio vadovo dalis – ką daryti su atsakymu.

Nuspręskite savininką, prieš liesdami klientą

Taisyklė apie tai, kur sukuriamas šifruotas tekstas, o ne apie tai, kuri mašina rodo VPN piktogramą. Jei jį sukuria svečias, svečiui reikia veikiančio maršruto į VPN serverį ir nieko daugiau iš hosto. Jei jį sukuria hostas, svečio kelias per hostą turi atlaikyti bet kokią politiką, kurią hosto klientas taiko vietiniam srautui.

Trys klausimai paprastai parenka talpinimą už jus. Ar svečio srautas turi atlaikyti įmonės klientą hoste? Tada tunelis yra svečio viduje. Ar keliems svečiams reikia vieno kredencialo ir vieno išėjimo adreso? Tada jis yra hoste, o persiuntimas sąmoningai sukonfigūruotas. Ar svečio srautas turi likti visiškai už hosto VPN? Tada tunelis svečiame yra vienintelė tvarka, kuri tai duoda pačia konstrukcija.

Užrašykite atsakymą viena eilute prie VM pavadinimo: guest-owned arba host-owned. Šešių mašinų laboratorijoje ta pastaba sutaupo daugiau laiko nei bet kuris žingsnis žemiau, nes neleidžia jums ieškoti gedimo tunelyje, kurio niekada nebuvo mašinoje, į kurią prisijungėte.

WSL1 ir WSL2 yra priešingi atvejai

WSL1 nėra virtualioji mašina, todėl talpinimo klausimas daugiausia išnyksta. Jo Linux dvejetainiai failai veikia prieš Windows tinklo kamieną per vertimo sluoksnį, o Linux VPN klientas neturi nepriklausomų sąsajų, kurias reikėtų konfigūruoti. Veikianti tvarka yra tunelis Windows pusėje, o distribucija naudoja rezultatą nieko nevaldydama.

WSL2 yra priešingai. Jis paleidžia tikrą branduolį lengvoje pagalbinėje VM už virtualaus Hyper-V komutatoriaus, o jo adresų erdvė NAT verčiama per hosto pusės adapterį. Todėl Linux klientas distribucijos viduje elgiasi kaip fizinėje Linux dėžėje: sukuria tun0 arba wg0, įdiegia savo maršrutus ir veikia. Gedimas gyvena hosto pusėje. Kai Windows VPN klientas prisijungia su politika, kuri blokuoja srautą vietiniuose tinkluose, jis WSL2 potinklį laiko nepatikimu vietiniu tinklu ir nukerta NAT kelią. Tada distribucija netenka DNS ir išorinės prieigos, nors jos pačios tunelis dar sveikas: wg show praneša apie rankos paspaudimą, ip route atrodo teisingai, o curl pakimba.

Kurią pataisą galite naudoti, priklauso nuo Windows versijos. Senesnė yra hosto kliento išimtis WSL potinkliui, pridedama prie kliento vietinio tinklo arba padalinto tunelio nustatymų. Naujesnė, palaikančiose Windows 11 versijose, yra veidrodinis tinklas: įdėkite networkingMode=mirrored į %UserProfile%\.wslconfig skyrių [wsl2], paleiskite wsl --shutdown, ir distribucija dalinsis hosto sąsajomis, o ne privačiu NAT potinkliu. Veidrodinis režimas taip pat keičia localhost ir įeinančių portų elgseną, todėl traktuokite jį kaip migraciją, o ne kaip jungiklį.

NAT, tiltas ir ką hostas gali matyti

Po NAT svečio tunelio paketai adresuojami VPN serverio viešuoju adresu ir išeina per hosto adapterį kaip šifruotas UDP arba TCP. Hostas mato vieną srautą ir jo baitų skaičių, nieko apie paskirties vietas jame. Po tiltiniu adapteriu svečias turi savo 2-ojo sluoksnio tapatybę fiziniame LAN, pasiima savo DHCP nuomą ir bet kokiai MAC pagrįstai politikai atrodo kaip antras įrenginys. Nė vienas režimas neleidžia hostui skaityti tunelio turinio; tiltinis svečias tiesiog yra daug labiau matomas aplinkiniam tinklui.

Izoliacija taip pat turi apatinę ribą. Svečias negali pasislėpti nuo mašinos, kuri valdo jo atmintį, o kas kontroliuoja hostą, gali skaityti raktus iš svečio RAM. Tai, ką duoda tunelis svečiame, yra maršrutizavimo ir kenkėjiškų programų riba, o ne apsauga nuo žmogaus, laikančio nešiojamąjį kompiuterį. Dokumentuotus adapterio režimus verta laikyti atidarytus renkantis, nes režimas keičia ir tai, ką mato hostas, ir tai, ką mato LAN.

Vadovas: įdėkite, sukonfigūruokite, įrodykite

Atlikite šiuos keturis patikrinimus iš eilės naujame svečio apvalkale ir sustokite prie pirmo, kuris nesutampa su užrašytu savininku.

1. ip route get 1.1.1.1, grąžinantis tun0 arba wg0, reiškia svečio nuosavybę, o eth0 su privačiu kitu šuoliu reiškia hosto nuosavybę.
2. resolvectl query example.com, arba perskaitykite /etc/resolv.conf ten, kur svečias nevaldo resolverio paslaugos. Tunelis, kuris neša srautą, bet ne DNS, yra labiausiai paplitusi pusiau sukonfigūruota būsena.
3. Palyginkite išėjimus: curl -4 -s https://ifconfig.me svečiame prieš curl.exe -4 -s https://ifconfig.me hoste. Skirtingi adresai reiškia, kad svečias valdo tunelį, o hostas VPN tinkle su svečiu, rodančiu namų tiekėją, yra atvejis, kai nieko nepaveldėta.
4. Pakartokite abu su -6. Tik v4 tunelis nutekina v6, nebent klientas jį blokuoja arba maršrutizuoja, ir daugelis klientų pagal nutylėjimą palieka v6 fizinėje sąsajoje.

Projektuojant hosto šliuzą, kai keli svečiai dalijasi vienu tuneliu, hostas turi persiųsti ir versti. Linux hoste tai trys dalys, ir svečias tyliai grįžta prie įprasto maršruto, kai kurios nors trūksta:

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

WireGuard pusėje hosto partnerio AllowedIPs turi apimti svečių potinklį, pavyzdžiui 192.168.122.0/24, kitaip grįžtamieji paketai niekada neatvyks ir sąranka atrodys kaip ugniasienės problema. Windows hostas pasiekia tą patį rezultatą su Interneto ryšio bendrinimu arba NAT taisykle Hyper-V komutatoriuje ir jam reikia to paties grįžimo kelio patikrinimo.

Kai išdėstymas dar atviras, ši lentelė apima dažniausiai pasitaikančias tvarkas:

Du tuneliai, du svečiai ir konfliktai tarp jų

Kai reikia dviejų išėjimų vienu metu, atlaikantis modelis yra vienas tunelis vienam svečiui. Kiekviena VM laiko savo numatytąjį maršrutą ir resolverį, hostas lieka įprastame tinkle, ir du tuneliai niekada nesiginčija dėl tos pačios maršrutizavimo lentelės. Dviejų svečių sujungimas tiltu taip pat nesujungia jų maršrutų: virtualus tinklas suteikia kelią, ir kiekvienam klientui vis tiek reikia pasakyti, kad šis vietinis srautas gali apeiti tunelį.

Hosto tunelio ir svečio tunelio paleidimas kartu yra teisėtas, o sąmoningas įdėjimas kartais yra būtent tai, ko norite, kai svečias išeina per savo tunelį, o tas tunelis išeina per hosto. Tai paverčia triktimi tai, kad niekas neužrašė, kuris galinis taškas per kurį sluoksnį turi būti pasiektas. Laikykite dviejų stulpelių sąrašą su paskirties vieta ir savininku, ir maršruto konfliktas tampa paieška, o ne atradimų popietė.

Patikrinkite, o tada palikite atkūrimą savininkui

Išbandykite svečio viduje su nauju programos procesu: srautas, vardų sprendimas, abi adresų šeimos ir kas nutinka, kai tunelis nukrenta. Hosto VPN piktograma nieko nesako apie svečio aprėptį, ir tai yra labiausiai paplitęs klaidingas patvirtinimas visoje šioje srityje.

Atkūrimas taip pat priklauso savininkui. Svečio valdomas tunelis atkuriamas paties svečio klientu ir jo užrašytais maršrutais. Hoste valdomas sprendimas atkuriamas hosto paleidimo seka, o persiuntimo taisyklės neišlieka po pakartotinio paleidimo, nebent unit arba paleidimo užduotis jas vėl pritaiko. Atkurta momentinė kopija yra diegimas, o ne atšaukimas, nes ji grąžina senus kredencialus ir senus maršrutus kartu su disku. Prieš paskelbdami darbą baigtu, patvirtinkite, kad savininkas vis dar atitinka užrašytą eilutę, kad DNS ir abi adresų šeimos sprendžiamos svečio viduje, kad negyvas tunelis palieka naudojamą tinklą, o ne juodąją skylę, ir kad pakartotinis paleidimas ar momentinės kopijos atkūrimas atkartoja tą pačią būseną.