OpenVPN nu se conectează la Wi-Fi-ul hotelului? Încearcă TCP 443

Deschide clientul, apasă Conectare și citește linia de stare în locul dialogului care apare după ea. Un profil care se blochează pe Se conectează sau Așteaptă serverul după o rețea de hotel, campus sau mobilă de obicei și-a pierdut transportul undeva pe traseu, nu acreditările. Următorul pas util este să afli ce transportă acea rețea înainte de a atinge serverul. Nu schimba nimic până când același profil nu a funcționat altundeva.

Testează mai întâi de pe un hotspot de telefon. Dacă tunelul urcă acolo, serverul, certificatul și contul sunt în regulă, iar singura variabilă rămasă este rețeaua din fața ta.

Începe de la client: citește linia de stare

Linia de stare îți spune ce etapă a eșuat. Un client blocat pe Se conectează încă rezolvă numele gazdei sau deschide socketul exterior; unul care ajunge la Așteaptă serverul are o cale, dar nu are răspuns; unul care se autentifică și apoi cade are o problemă complet diferită. Jurnalul clientului și câmpurile remote și proto ale profilului arată ce încearcă clientul să facă, iar --verb 4 pe un client din linia de comandă tipărește același detaliu. Compararea acestora cu rețeaua din fața ta este ce transformă 'VPN-ul este blocat' într-o afirmație concretă.

Apoi sondază rețeaua cu instrumentele pe care le ai deja. nc -vzu 203.0.113.10 1194 trimite un datagram UDP, curl -v telnet://203.0.113.10:443 raportează dacă strângerea de mână TCP se finalizează, iar un browser care încarcă o pagină HTTPS dovedește doar că ieșirea 443 ajunge la acea singură gazdă. Sondajele mici răspund la ce clientul VPN nu poate: ce port și ce protocol ies de fapt din această rețea.

Trei comportamente de rețea arată la fel din client și cer răspunsuri diferite. Ieșirea 443 poate fi deschisă, poate fi permis doar un proxy, sau 443 poate fi trimis transparent către o cutie de inspecție care nu poate citi ce transportă. Prima se rezolvă prin schimbarea profilului de mai jos, a doua prin setările de proxy, iar a treia poate finaliza strângerea de mână și apoi se poate bloca atunci când inspectorul decide că nu-i place fluxul. Să știi cu care dintre cele trei te confrunți este diferența dintre o schimbare de zece minute și o după-amiază de reinstalat clienți.

Mută listenerul și profilul împreună

Pe partea de server, setează listenerul la ce permite rețeaua: port 443 și proto tcp în configurația serverului, apoi repornește serviciul și confirmă socketul cu ss -lntp. Pe partea de client, profilul trebuie să fie de acord, deoarece transportul și portul stau în afara tunelului: proto tcp și port 443 în .ovpn, sau câmpurile corespunzătoare din ecranul de setări al aplicației. Un profil încă orientat spre UDP 1194 eșuează exact ca înainte, iar tentația este să dai vina pe un firewall deja reparat. Dacă aceeași gazdă răspunde și la HTTPS pe 443, cele două listenere nu pot împărți acea adresă și acel protocol; dă VPN-ului o a doua adresă sau pune un demultiplexor în față.

Urmărește prima conexiune cu tcpdump -ni any port 443 la ambele capete. Pachetele care pleacă de la client și nu ajung niciodată înseamnă că rețeaua filtrează totuși, sau că adresa din profil nu este cea pe care o presupui. Pachetele care ajung fără răspuns te trimit înapoi la jurnalul serverului, unde o nepotrivire de protocol apare imediat ca pachet aruncat.

Când doar un proxy iese din rețea

Unele rețele pentru oaspeți nu permit nimic altceva decât un proxy HTTP, ceea ce este o constrângere diferită de un port închis și exclude mai mult decât OpenVPN. Clienții care vorbesc doar PPTP, L2TP/IPsec sau IPsec gol nu au cum să treacă printr-unul, pentru că acele proiecte se așteaptă ca protocolul lor exterior să ajungă direct la server. OpenVPN poate, cu http-proxy proxy.example.net 8080 în profilul clientului, cu condiția ca proxy-ul să permită metoda CONNECT către portul tău. Un proxy SOCKS este chiar mai simplu, pentru că transmite fluxul fără să-i pese ce este înăuntru.

Acolo unde clientul nu are suport de proxy, un tunel SSH peste 443 este de obicei ce rămâne. Adaugă un al doilea strat, iar operatorul rețelei poate avea o părere despre asta, așa că tratează-l ca pe o punte pentru o singură călătorie, nu ca pe o arhitectură.

Estimează costul soluției de rezervă înainte de a o păstra

TCP în interiorul TCP are un cost cunoscut. Când conexiunea exterioară este TCP și încărcătura este tot TCP, un segment pierdut declanșează retransmisie pe ambele straturi, iar conexiunea interioară dă înapoi în fața unei pierderi pe care nu o poate vedea. Navigarea rezistă; sesiunile interactive și apelurile o simt. Păstrează listenerul TCP 443 ca rezervă pentru rețelele care îl cer și lasă UDP ca implicit pentru tot ce încă îl lasă să treacă.

Notează alegerea în numele profilului și în notele de suport: ce port, ce protocol și ce rețea a provocat-o. Apoi întreabă administratorul rețelei dacă acel port rămâne deschis după următoarea schimbare de echipamente, pentru că o rezervă care dispare în tăcere este mai rea decât nicio rezervă.