Rularea VPN pe gazdă sau în interiorul VM? Ghid de decizie

Construirea tunelului în interiorul oaspetelui și construirea lui pe gazdă schimbă ambele adresa pe care o raportează un browser, și acolo se termină asemănarea. Un tunel deținut de oaspete își păstrează cheile, ruta implicită și resolverul în nucleul oaspetelui, în timp ce gazda trimite pachete criptate către o singură adresă îndepărtată. Un tunel deținut de gazdă este imaginea în oglindă: clientul gazdei ține sesiunea și aplică rute și politică, iar oaspetele împrumută ce iese afară. Alegeți proprietarul greșit și fiecare simptom ulterior vă trimite la mașina greșită. Două comenzi lămuresc întrebarea în aproximativ un minut, iar restul acestui ghid este ce faceți cu răspunsul.

Decideți proprietarul înainte să atingeți clientul

Regula se referă la locul unde este produs textul cifrat, nu la ce mașină afișează o pictogramă VPN. Dacă oaspetele îl produce, oaspetele are nevoie de o rută funcțională către serverul VPN și de nimic altceva de la gazdă. Dacă gazda îl produce, oaspetele are nevoie ca drumul prin gazdă să supraviețuiască oricărei politici pe care clientul gazdei o impune traficului local.

Trei întrebări aleg de obicei plasarea pentru dumneavoastră. Traficul oaspetelui trebuie să supraviețuiască unui client corporativ de pe gazdă? Atunci tunelul este în oaspete. Mai mulți oaspeți au nevoie de o singură acreditare și de o singură adresă de ieșire? Atunci este pe gazdă, cu redirecționarea configurată intenționat. Traficul oaspetelui trebuie să rămână complet în afara VPN-ului gazdei? Atunci un tunel în oaspete este singura așezare care vă dă asta prin construcție.

Notați răspunsul pe o linie lângă numele VM-ului: guest-owned sau host-owned. Într-un laborator de șase mașini acea notă economisește mai mult timp decât orice pas de mai jos, pentru că vă împiedică să diagnosticați un tunel care nu a fost niciodată în mașina la care v-ați conectat.

WSL1 și WSL2 sunt cazuri opuse

WSL1 nu este o mașină virtuală, așa că întrebarea plasării se evaporă în mare parte. Binarele sale Linux rulează împotriva stivei de rețea Windows printr-un strat de traducere, iar un client VPN Linux nu are interfețe independente de configurat. Așezarea care funcționează este un tunel pe partea Windows, distribuția folosind rezultatul fără a deține nimic.

WSL2 este invers. Rulează un nucleu real într-un VM utilitar ușor în spatele unui comutator virtual Hyper-V, iar spațiul său de adrese este tradus prin NAT printr-un adaptor de pe partea gazdei. De aceea un client Linux din distribuție se comportă ca pe o cutie Linux fizică: creează tun0 sau wg0, își instalează propriile rute și funcționează. Defecțiunea trăiește pe partea gazdei. Când un client VPN Windows se conectează cu o politică ce blochează traficul în rețelele locale, tratează subrețeaua WSL2 ca pe o rețea locală nesigură și taie calea NAT. Distribuția pierde atunci DNS și accesul de ieșire în timp ce propriul tunel este încă sănătos: wg show raportează o strângere de mână, ip route arată corect, iar curl se blochează.

Ce remediere puteți folosi depinde de build-ul Windows. Cea mai veche este o excepție în clientul gazdei pentru subrețeaua WSL, adăugată sub setările de rețea locală sau tunel divizat ale clientului. Cea mai nouă, pe build-urile Windows 11 care o acceptă, este rețelistica în oglindă: puneți networkingMode=mirrored în secțiunea [wsl2] din %UserProfile%\.wslconfig, rulați wsl --shutdown, iar distribuția partajează interfețele gazdei în locul unei subrețele NAT private. Modul oglindă schimbă și comportamentul localhost și al porturilor de intrare, așa că tratați-l ca pe o migrare și nu ca pe un comutator.

NAT, punte și ce poate vedea gazda

Sub NAT, pachetele tunelului oaspetelui sunt adresate adresei publice a serverului VPN și ies prin adaptorul gazdei ca UDP sau TCP criptat. Gazda vede un singur flux și numărul său de octeți, nimic despre destinațiile din interior. Sub un adaptor în punte, oaspetele are propria identitate de nivel 2 în LAN-ul fizic, își ia propriul lease DHCP și apare pentru orice politică bazată pe MAC ca un al doilea dispozitiv. Niciunul dintre moduri nu lasă gazda să citească sarcina tunelului; oaspetele în punte este pur și simplu mult mai vizibil pentru rețeaua din jur.

Izolarea are și ea un prag de jos. Un oaspete nu se poate ascunde de mașina care îi deține memoria, iar cine controlează gazda poate citi chei din RAM-ul oaspetelui. Ce vă dă un tunel în oaspete este o graniță de rutare și o graniță împotriva programelor malițioase, nu protecție față de persoana care ține laptopul. Merita să aveți deschise modurile de adaptor documentate în timp ce alegeți, deoarece modul schimbă atât ce vede gazda, cât și ce vede LAN-ul.

Ghid: plasați-l, configurați-l, demonstrați-l

Rulați aceste patru verificări în ordine într-un shell de oaspete nou și opriți-vă la prima care nu se potrivește cu proprietarul notat.

1. ip route get 1.1.1.1 care returnează tun0 sau wg0 înseamnă proprietate a oaspetelui, iar eth0 cu un salt următor privat înseamnă proprietate a gazdei.
2. resolvectl query example.com, sau citiți /etc/resolv.conf acolo unde oaspetele nu rulează niciun serviciu de resolver. Un tunel care transportă trafic dar nu DNS este starea pe jumătate configurată cea mai frecventă.
3. Comparați ieșirile: curl -4 -s https://ifconfig.me în oaspete față de curl.exe -4 -s https://ifconfig.me pe gazdă. Adrese diferite înseamnă că oaspetele deține tunelul, iar o gazdă în VPN cu un oaspete care arată furnizorul de acasă este cazul în care nu s-a moștenit nimic.
4. Repetați ambele cu -6. Un tunel doar v4 scurge v6 dacă clientul nu îl blochează sau îl rutează, iar mulți clienți lasă v6 pe interfața fizică în mod implicit.

Pentru un proiect cu poartă pe gazdă, unde mai mulți oaspeți împart un tunel, gazda trebuie să redirecționeze și să traducă. Pe o gazdă Linux sunt trei piese, iar oaspetele revine în tăcere la ruta sa simplă când lipsește oricare dintre ele:

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

Pe partea WireGuard, AllowedIPs al partenerului gazdei trebuie să includă subrețeaua oaspeților, de exemplu 192.168.122.0/24, altfel pachetele de retur nu ajung niciodată și configurația arată ca o problemă de firewall. O gazdă Windows obține același rezultat cu Partajarea conexiunii la internet sau cu o regulă NAT pe comutatorul Hyper-V și are nevoie de aceeași verificare a căii de retur.

Când așezarea este încă deschisă, acest tabel acoperă aranjamentele cele mai frecvente:

Două tuneluri, doi oaspeți și conflictele dintre ele

Când aveți nevoie de două ieșiri simultan, modelul care rezistă este un tunel pe oaspete. Fiecare VM își păstrează ruta implicită și resolverul, gazda rămâne în rețeaua obișnuită, iar cele două tuneluri nu se ceartă niciodată pe aceeași tabelă de rutare. Punerea a doi oaspeți în punte nu le unește nici rutele: rețeaua virtuală oferă o cale, iar fiecărui client trebuie să i se spună în continuare că acest trafic local poate ocoli tunelul.

Rularea unui tunel de gazdă și a unui tunel de oaspete împreună este legitimă, iar imbricarea deliberată este uneori exact ce vă doriți, oaspetele ieșind prin propriul tunel, iar acel tunel ieșind prin al gazdei. Ce o transformă în întrerupere este că nimeni nu a notat care punct final trebuie atins prin ce strat. Țineți o listă cu două coloane cu destinație și proprietar, iar un conflict de rute devine o căutare în loc de o după-amiază de descoperire.

Verificați, apoi lăsați recuperarea la proprietar

Testați din interiorul oaspetelui cu un proces de aplicație nou: trafic, rezolvare de nume, ambele familii de adrese și ce se întâmplă când tunelul cade. Pictograma VPN a gazdei nu spune nimic despre acoperirea oaspetelui, și aceasta este cea mai frecventă confirmare falsă din tot acest domeniu.

Recuperarea aparține și ea proprietarului. Un tunel deținut de oaspete este restaurat de clientul propriu al oaspetelui și de rutele pe care le-a scris. Un proiect deținut de gazdă este restaurat de secvența de pornire a gazdei, iar regulile de redirecționare nu supraviețuiesc unei reporniri decât dacă o unitate sau o sarcină de pornire le aplică din nou. Un instantaneu restaurat este o implementare, nu o anulare, pentru că aduce înapoi acreditări vechi și rute vechi împreună cu discul. Înainte de a declara lucrarea terminată, confirmați că proprietarul corespunde încă liniei notate, că DNS și ambele familii de adrese se rezolvă în interiorul oaspetelui, că un tunel mort lasă o rețea utilizabilă în loc de o gaură neagră și că o repornire sau o restaurare de instantaneu reproduce aceeași stare.