VPN blocat într-o rețea doar web? Lucrați pe straturi

O rețea de campus sau de hotel în care browserul funcționează și fiecare tunel moare nu este o problemă, ci patru suprapuse. Calea poate permite doar TCP 443, poate cere un proxy autentificat, poate inspecta handshake-ul sau poate pur și simplu interzice accesul la distanță prin politică. Tratarea lor în ordine te scutește de a cumpăra un client nou pentru a repara o regulă de rețea. Ghidul de mai jos durează aproximativ zece minute și se termină cu un răspuns scris despre ce strat te-a refuzat.

Demonstrați ce strat refuză conexiunea

Nu începeți cu clientul VPN. Începeți cu o cerere HTTPS simplă către același host și citiți fazele de timp, pentru că faza care eșuează spune ce dispozitiv este responsabil:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Fără răspuns și fără timp connect înseamnă că TCP nu s-a finalizat niciodată, deci un firewall, o cerință de proxy sau o destinație greșită este în joc. Un timp connect fără timp tls înseamnă că ceva din mijloc a acceptat conexiunea și apoi a blocat handshake-ul, iar așa arată un proxy de inspecție din partea clientului.

Acum inspectați certificatul pe care îl primiți de fapt. Este cea mai rapidă cale de a afla dacă vorbiți cu serverul sau cu o cutie intermediară care a resemnat sesiunea:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Citiți linia emitentului. CA-ul propriu înseamnă că ați ajuns la serviciu; un emitent corporativ sau de dispozitiv înseamnă că un filtru a terminat conexiunea și decide ce urmează. Înregistrați ambele ieșiri cu un marcaj de timp, pentru că același test o oră mai târziu în rețeaua pentru oaspeți poate da alt răspuns.

Un client conștient de proxy schimbă primul pachet, nu politica

Dacă rețeaua cere CONNECT printr-un proxy autentificat, clientul VPN trebuie anunțat, altfel va încerca să deschidă un socket către o adresă pe care nu o poate ruta. Testați proxy-ul separat de client, ca o eșuare să aibă o singură explicație:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Prima comandă demonstrează că proxy-ul va transporta destinația. A doua cere clientului să folosească TCP pe 443, singurul transport pe care majoritatea căilor doar web îl lasă să treacă. Dacă prima reușește și a doua tot eșuează, proxy-ul nu este obstacolul.

Unii clienți citesc proxy-ul sistemului de operare în loc de o suprascriere, iar unii nu citesc niciunul. Verificați documentația aplicației înainte de a presupune că o setare la nivel de sistem se aplică. Un client care rezolvă punctul final printr-un resolver pe care proxy-ul nu îl deservește va eșua și aici, și de aceea o schimbare DNS poate părea o soluție când este doar un ocol.

Observați și tiparul de dirijare. O rețea filtrată poate răspunde numelui de gazdă de detectare al unui furnizor cu ceva propriu, ceea ce schimbă ce profil de proxy alege clientul. Nu construiți un proces în jurul acelei ciudățenii. Variază de la un sit la altul, se schimbă fără anunț și nu este ceva ce puteți susține pentru altcineva.

Portul 443 este accesibil, nu permis

Învelirea unui tunel în TLS pe 443 rezolvă accesibilitatea și nimic altceva. Un filtru care verifică portul îl va lăsa să treacă; un filtru care ia amprenta handshake-ului nu, iar client hello criptat ascunde numele serverului doar când ambele capete îl susțin. Rulați testul și aflați în spatele cărui tip de filtru sunteți în loc să sperați.

Există și un cost de performanță pe care oamenii îl descoperă mai târziu. Un transport fiabil într-un transport fiabil amplifică pierderea, pentru că stiva interioară retransmite segmente pe care stiva exterioară le-a retransmis deja. Pe o legătură curată nimeni nu observă. Într-o rețea wireless de campus congestioanată tunelul devine inutilizabil exact când ai nevoie de el, iar graficul arată ca pierdere de pachete deși nimic nu este aruncat intenționat.

UDP este de obicei prima victimă, și merită confirmat în loc de presupus. Dacă WireGuard sau OpenVPN implicit nu finalizează niciodată un handshake în timp ce TCP 443 funcționează, rețeaua aruncă UDP, iar nicio regenerare de chei nu va schimba asta:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Un marcaj de timp gol al handshake-ului lângă un peer care funcționa ieri este răspunsul UDP. Cele două interogări DNS răspund la altă întrebare: dacă resolverul local și un resolver public nu sunt de acord asupra adresei punctului final, sunteți dirijat și argumentul despre transport este cel greșit.

Verificați ce a părăsit de fapt mașina

Jurnalele clientului descriu ce crede clientul. O captură descrie ce a văzut rețeaua, iar diferența dintre cele două este locul unde se rezolvă majoritatea acestor cazuri:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Dacă vedeți pachete SYN și niciun SYN-ACK, blocajul este în amonte și clientul este nevinovat. Dacă vedeți un handshake finalizat către o adresă care nu este a serverului, vorbiți cu un proxy sau un interceptator. Dacă nu vedeți nimic, verificați că ați capturat pe interfața corectă înainte de a concluziona ceva.

Lista de socket-uri prinde un caz mai subtil: un al doilea tunel care deține deja ruta implicită. Doi clienți care se luptă pentru tabela de rutare produc eșecuri intermitente care arată exact ca o rețea blocată, iar captura va arăta trafic care iese printr-o interfață la care nu vă așteptați.

Revenirea și nota care merită păstrată

Anulați modificările în ordinea inversă celei în care le-ați făcut. Eliminați variabilele de proxy, opriți clientul pornit manual și scoateți orice suprascriere de rută sau resolver pe care ați adăugat-o:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

A lăsa un client pornit manual să ruleze este felul în care un laptop ajunge cu rețeaua stricată la următoarea vizită la birou. Variabilele de proxy lăsate într-un profil de shell strică unelte nelegate săptămâni mai târziu, iar persoana care le depanează nu va face legătura între cele două evenimente.

Apoi scrieți patru rânduri: rețeaua, marcajul de timp, faza care a eșuat și emitentul pe care l-ați văzut. O cale care funcționează pe un campus și eșuează pe următorul este normală, iar următoarea persoană trebuie să știe dacă diferența a fost proxy-ul, resolverul sau filtrul. Dacă răspunsul este că rețeaua interzice accesul la distanță, opriți-vă acolo și cereți administratorului ruta suportată în loc să duceți un ocol într-o politică pe care nu ați citit-o.