VPN în spatele unui NAT pe care nu îl puteți configura: ce încă funcționează

Fiecare capăt de tunel are nevoie de o adresă și un port pe care cealaltă parte le poate atinge, iar un router pe care nu îl administrați este motivul obișnuit pentru care această cerință eșuează. Partea interesantă nu este că există trucuri, ci că fiecare depinde de o proprietate a unui tabel de mapare pe care nu o vedeți din client. Două dintre aceste proprietăți decid aproape totul: cum se creează o mapare și dacă acceptă pachete de la o adresă cu care interiorul nu a comunicat niciodată. Sortați mediul după aceste proprietăți și soluțiile ocolitoare nu mai sunt folclor.

Tabelul de mapare decide totul

Traducerea adreselor de rețea ține un tabel în care o adresă și un port interne sunt înregistrate față de o adresă și un port publice. Răspunsurile care corespund unei înregistrări sunt traduse înapoi, iar un pachet care vine din exterior fără o înregistrare potrivită nu are nicio destinație. Acest singur comportament explică de ce un ascultător din spatele routerului este inaccesibil din internet. Explică și de ce primul pachet din fiecare direcție trebuie să provină din interior.

Priviți tabelul din partea routerului și soluțiile devin evidente: fie ceva creează o intrare permanentă, fie creează una temporară și o menține proaspătă, fie traficul nu ia niciodată acea cale. Restul articolului sunt aceste trei cazuri în ordine. Nimic aici nu depinde de o funcție a furnizorului dincolo de ce înregistrează tabelul.

Ce poate și ce nu poate face serviciul de întâlnire

Hole punching UDP folosește înregistrarea de ieșire ca o deschidere temporară în loc să învingă filtrul. Ambii parteneri contactează un serviciu de întâlnire, care află fiecare capăt public și raportează celeilalte părți capătul ei. Apoi amândoi trimit unul spre celălalt, iar fiecare pachet de ieșire creează sau reîmprospătează înregistrarea care lasă răspunsul să intre. Ordinea este cea care îl face să funcționeze, iar ordinea este și cea care îl face fragil: un partener care trimite înainte ca cealaltă parte să își fi creat înregistrarea este pur și simplu aruncat, în timp ce o nouă încercare o clipă mai târziu reușește. Serviciul în sine nu transportă trafic VPN, așa că singura sa pârghie este sincronizarea pe care o coordonează.

Comportamentul mapării decide restul, iar RFC 4787 numește cele trei forme: independentă de capăt, dependentă de adresă și dependentă de adresă și port. La ultima, portul pe care un partener trebuie să îl vizeze se schimbă cu fiecare destinație, așa că predicția nu mai este fiabilă. Acolo tehnica ajunge în fundături, pentru că NAT-ul de nivel de operator și un firewall corporativ strict elimină amândouă predictibilitatea de care are nevoie schema, și nicio cantitate de reîncercări nu o aduce înapoi.

Keepalive, reporniri și capătul care se mișcă

O cale perforată este un flux, nu un ascultător, așa că tot ce rulează deasupra ei trebuie să supraviețuiască schimbării. Trebuie să mențină maparea vie cu trafic periodic, să observe când capătul public se mișcă și să se restabilească după repornirea routerului sau realocarea adresei. Produsele mesh VPN pun acea logică în propriul plan de control, în timp ce un server simplu o lasă în seama voastră. Keepalive ajută doar cât timp supraviețuiește aceeași mapare și consumă baterie pe un client mobil, de aceea un interval agresiv nu este gratuit.

Un laptop care doarme o oră se întoarce de obicei pe un alt capăt public. Tot ce restabilește calea trebuie să ruleze din nou din interior, ceea ce pune aceeași cerință înapoi pe client.

Trei moduri de a ocoli o redirecționare lipsă

Primul mod cere routerului să creeze el însuși intrarea, prin UPnP IGD, NAT-PMP sau PCP, când funcția există și este pornită. Al doilea predă traficul unui releu cu adresă publică, care funcționează întotdeauna și costă întotdeauna lățime de bandă plus o altă graniță de încredere. Al treilea inversează direcția: gazda internă deschide un tunel de ieșire către un server public și tot restul călătorește în interiorul lui.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Un capăt de releu face acel schimb vizibil în configurația clientului, unde capătul este un releu și nu adresa proprie a unui partener. Keepalive-ul persistent menține maparea caldă, iar prefixele permise decid ce poate clientul să trimită prin ea. Un tunel invers de la gazda internă este aceeași idee cu alt proprietar și nu necesită nicio modificare a NAT-ului. Fiecare dintre cele trei elimină cerința de intrare fără a învinge un firewall care blochează prin proiectare traficul nesolicitat, pentru că traficul tot începe în interior.

Potriviți soluția cu cine deține routerul

Dacă administrați routerul, o redirecționare UDP statică este mai ușor de auditat decât orice schemă de perforare și eșuează în moduri pe care le vedeți. Dacă nu, aflați dacă furnizorul oferă un releu sau un plan de control găzduit și dacă politica ar permite folosirea lui. Dacă niciunul nu este disponibil, opțiunile rămase sunt un tunel invers sau acceptarea faptului că capătul nu este accesibil din exterior. Notarea celui folosit contează mai mult decât pare, pentru că opțiunile diferă prin cine poate observa traficul și ce se întâmplă când o terță parte schimbă ceva.

Observați dacă calea la care ați ajuns a fost directă sau prin releu, deoarece acest singur fapt prezice atât latența, cât și comportamentul la defecțiune. RFC 4787 rămâne referința pentru comportamentul mapării de dedesubt, iar citirea secțiunii sale despre mapare este mai rapidă decât testarea a trei soluții la rând. Tabelului nu îi pasă ce opțiune ați ales; înregistrează doar ce are voie să facă următorul pachet.