De ce un profil OpenVPN funcționează acasă dar eșuează într-un hotel

Wi-Fi-ul de la birou și o cameră de hotel pot oferi aceluiași laptop două rețele foarte diferite, iar profilul dintre ele nu știe nimic despre asta. Ce funcționează acasă presupune un uplink permisiv, rezolvarea numelor funcțională și o subrețea locală care nu se ciocnește cu nimic din ce transportă tunelul. Fiecare dintre aceste presupuneri poate eșua separat.

Modul util de a depana această problemă este să tratezi rețeaua ca patru fapte separate, apoi să le testezi în ordine. Ghiceala la profil mai întâi produce de obicei o schimbare care nu repară nimic și ascunde dovezile.

Patru fapte de rețea se schimbă între locații

Primul fapt este dacă rețeaua locală te lasă să ieși deloc. Un portal de autentificare admite un dispozitiv pe o pagină de conectare și blochează tot restul până când acea pagină este finalizată, ceea ce înseamnă că tunelul nu poate porni, oricât de corect ar fi profilul.

Al doilea este rezolvarea numelor. Un portal care interceptează DNS răspunde fiecărei interogări cu propria adresă, astfel încât numele de gazdă al VPN se rezolvă la portal și clientul încearcă să construiască un tunel către o pagină web.

Al treilea este filtrarea transportului. Rețelele care vor să permită doar navigarea lasă TCP 443 să treacă spre destinații arbitrare și aruncă aproape tot restul, inclusiv UDP.

Al patrulea este adresarea. Subrețeaua locală se poate suprapune cu o rețea din spatele tunelului, sau uplink-ul poate să nu ofere nicio cale IPv4 utilizabilă.

Rezolvarea numelor și portalul de autentificare

Înlocuiește numele de gazdă din profil cu adresa numerică a serverului și încearcă din nou. Dacă IP-ul se conectează și numele nu, vina este la rezolvarea numelor, iar profilul în sine este în regulă.

Deschide un browser și încearcă o pagină HTTP obișnuită înainte de a atinge VPN-ul. O redirecționare către o pagină de conectare înseamnă că portalul este încă în așteptare; finalizeaz-o, apoi reconectează-te. Multe hoteluri expiră și sesiunea după câteva ore, ceea ce arată ca o deconectare la mijlocul zilei, nu ca o problemă de conectare.

Dacă și adresa numerică eșuează, rezolvarea numelor nu este explicația, așa că treci la transport. Păstrează adresa pe care ai testat-o, pentru că îi spune următoarei verificări dacă pachetele au părăsit măcar mașina.

Filtrarea transportului: mai întâi UDP, TCP 443 ca rezervă

Un flux OpenVPN prin UDP 1194 nu arată ca nimic ce recunoaște un firewall de hotel, așa că este aruncat fără eroare. Clientul reîncearcă până când expiră timpul său, iar utilizatorul vede o conexiune care nu se stabilește niciodată în loc de un refuz. Firewall-urile care se comportă astfel înregistrează rareori aruncarea într-un loc în care să o vezi. Absența unui refuz este în sine indiciul.

TCP 443 este rezerva fiabilă pentru că rețeaua nu îl poate distinge de un HTTPS obișnuit. Folosește profilul TCP al operatorului când există, deoarece și serverul trebuie să asculte pe acel transport și port; schimbarea doar a clientului produce un alt tip de eșec. Dacă nu există niciun profil TCP, întreabă operatorul în loc să inventezi unul editând portul. Partea serverului trebuie să fie de acord, iar o nepotrivire arată din nou ca o problemă de firewall.

Așteaptă-te la un cost de performanță. TCP în interiorul TCP amplifică retransmisiile pe o legătură cu pierderi, așa că un tunel TCP funcțional poate părea lent pe o rețea de hotel congestionată. Este un schimb pentru accesibilitate, nu un defect de urmărit.

Coliziuni de adrese și uplink-uri fără IPv4

Un tunel se poate stabili și totuși nu transporta nimic. Când LAN-ul local și o rețea îndepărtată împart un prefix precum 192.168.1.0/24, clientul consideră gazda îndepărtată conectată direct și trimite pachetul către legătura locală în locul tunelului. Simptomul este o conexiune reușită cu o subrețea inaccesibilă, ceea ce se citește ușor greșit ca o problemă de rută pe partea serverului.

Remedierea permanentă este mutarea LAN-ului îndepărtat într-un interval privat neobișnuit. Alegerea unui interval pe care nimeni nu îl folosește acasă, cum ar fi 10.42.0.0/24, previne problema pentru fiecare locație viitoare în loc de una singură. Soluția locală este să eviți acel hotel, hotspot sau router, ceea ce nu este deloc o remediere.

Uplink-urile mobile adaugă două variante. NAT la nivel de operator înseamnă că conexiunile de intrare nu ajung, ceea ce contează dacă găzduiești un server, dar nu pentru un client de ieșire. Un APN configurat doar cu IPv6 și traducere NAT64 poate face să eșueze un client care insistă pe o cale IPv4 reală, iar remediul obișnuit este schimbarea protocolului APN în IPv4 sau stivă dublă.

Simptome după ce tunelul este ridicat

Un tunel care se conectează și apoi tace este de obicei o problemă de keepalive sau MTU, nu un port blocat. O conexiune care cade după un număr fix de minute indică un temporizator de keepalive sau de renegociere. Setează clientul să-și sondeze partenerul și să repornească atunci când răspunsurile se opresc, și testează un MTU de tunel mai mic dacă ping-urile trec în timp ce transferurile mari se blochează.

Înainte să ceri ajutor, notează trei lucruri: adresa pe care ai încercat-o și dacă a răspuns, transportul și portul pe care le-ai folosit, și subrețeaua locală a rețelei care a eșuat. Împreună, ele separă rezolvarea numelor de filtrarea transportului și de o coliziune de adrese, iar acestea sunt cauzele care supraviețuiesc contactului cu dovezile.