OpenVPN pe 443 încă blocat? Verificați ce inspectează rețeaua

Tunelul se conectează de pe o linie de acasă și se blochează într-o rețea de hotel sau de birou, iar mutarea serverului pe portul 443 nu a schimbat nimic. Rezultatul este destul de obișnuit încât să aibă o formă: portul era partea ușoară, iar restul deciziei aparține tot ce stă între client și server. Două întrebări rezolvă majoritatea cazurilor, și niciuna nu este despre cifruri. Rețeaua acceptă un handshake TLS către acea adresă, și clientul păstrează o rută către propriul ambalaj cât timp tunelul este ridicat?

Handshake-ul trădează mai mult decât numărul

Un ascultător VPN nativ pe TCP 443 vorbește propriul protocol încă din primul pachet. Un ClientHello are un câmp de versiune, o valoare aleatoare și o listă de extensii, iar un dispozitiv care citește câteva sute de octeți poate vedea diferența fără să decripteze nimic. Numerele de port sunt ieftin de satisfăcut, iar forma protocolului este ceea ce verifică filtrul de fapt. Regulile se scriu de obicei și pe protocol, așa că o politică ce inspectează TLS nu spune nimic despre UDP.

Un proxy transparent care cere o sesiune TLS validă rupe conexiunea în timpul configurării, adesea după ce handshake-ul TCP s-a încheiat. Detaliul contează mai târziu, pentru că înseamnă că jurnalul clientului se oprește după ce socketul este stabilit.

Ambalarea fluxului creează două puncte de eșec

Un ambalaj TLS precum stunnel readuce forma așteptată: clientul se conectează la un ascultător local, ambalajul deschide o sesiune TLS reală către server pe 443, iar un al doilea ambalaj pe server trimite octeții decriptați către demonul VPN. Sesiunea exterioară arată acum ca orice altă conexiune HTTPS. Demonul VPN de pe server ar trebui să asculte doar pe loopback, pentru că nimic din afara ambalajului nu trebuie să ajungă la el.

Trei lucruri separate trebuie să se alinieze pentru acel proiect. Profilul clientului indică ascultătorul local, certificatul serverului corespunde numelui pe care clientul îl verifică, iar redirecționarea din partea serverului țintește portul pe care demonul îl folosește cu adevărat. Greșiți oricare dintre ele și conexiunea moare înainte de a ajunge la stratul VPN. O nepotrivire de certificat apare atunci ca eroare a ambalajului și nu ca eroare VPN, și de aceea merită citite ambele jurnale unul lângă altul.

Ruta către ambalaj este capcana

Imediat ce tunelul se ridică, ruta implicită indică în el, iar sesiunea TLS exterioară are nevoie de o cale care să nu intre în tunelul pe care îl transportă. Un client VPN obișnuit protejează adresa pe care o apelează; un client ambalat apelează propriul loopback, așa că adresa de destinație a ambalajului este invizibilă pentru acea protecție.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Adresele exacte le completați dumneavoastră, iar ruta trebuie să existe pe toată durata conexiunii, nu doar la pornire. Un mic script de ambalaj care adaugă ruta înainte de client și o elimină după este mai de încredere decât o comandă ținută minte.

Pe Android, echivalentul acelei excepții este o setare pentru fiecare aplicație: excludeți aplicația de ambalaj din tunel, ca traficul ei propriu să iasă prin conexiunea mobilă. Fără excludere, ambalajul este rutat în tunelul pe care încearcă să îl construiască, iar bucla de reconectare arată ca o problemă a serverului.

Citiți cronologia înainte de a schimba ceva

O sesiune care moare după același interval de fiecare dată este o semnătură de politică și nu o defecțiune criptografică, iar limitele de flux de lungă durată produc exact acel model. O conexiune care este resetată imediat după handshake sugerează un proxy căruia nu i-a plăcut lanțul de certificate.

Comparați emitentul certificatului unui site HTTPS obișnuit din ambele rețele. Dacă emitentul diferă în rețeaua restricționată, ceva termină TLS la mijloc, și niciun ambalaj nu va supraviețui acelei interceptări fără modificări. Aceeași comparație vă spune dacă blocarea vizează numele serverului dumneavoastră sau fiecare sesiune TLS de la acea adresă.

Notați comportamentul observat: cât a durat sesiunea, dacă socketul s-a deschis, dacă ambalajul a înregistrat un handshake. Fiecare dintre acestea îngustează testul următor.

Testați o singură variabilă odată

Verificați mai întâi UDP, pentru că unele rețele îl aruncă complet și o defecțiune UDP nu spune nimic despre 443. Apoi încercați TCP 443 fără ambalaj, apoi ambalajul pe 443. Citiți jurnalul clientului la fiecare pas și opriți-vă imediat ce comportamentul se schimbă.

Schimbați un element pe încercare. Un port nou, un ambalaj nou și un cifru nou în aceeași rulare vă lasă fără posibilitatea de a spune care dintre cele trei a contat.