De ce portalul captiv îți blochează VPN-ul și cum te conectezi din nou

Într-o rețea deschisă, punctul de acces nu predă pur și simplu pachetele internetului. Un punct de politică mai sus verifică dacă dispozitivul e deja autorizat, iar până când este, aproape totul e aruncat. Clientul tău VPN citește acea tăcere ca pe un server mort. Rar o spune: WireGuard repetă un handshake în gol, OpenVPN raportează un timeout al conexiunii, iar IKEv2 revine ca eroare 809 despre un server îndepărtat care nu răspunde.

Ce controlează de fapt portalul

Un portal captiv sunt două lucruri lipite împreună: un punct de decizie a politicii și un redirector. Când dispozitivul se asociază și ia un lease DHCP, rețeaua te pune într-o stare dinainte de autorizare.

Acea stare e un set de reguli de firewall. De obicei lasă DNS și permite HTTP sau HTTPS către o listă scurtă de gazde ale portalului, iar restul îl aruncă. Lista permisă e grădina împrejmuită și aproape niciodată nu include punctul final al VPN-ului.

Niciuna dintre aceste aruncări nu e politicoasă. Pachetele către un server VPN sunt aruncate în loc să fie refuzate, așa că clientul nu primește nici ICMP unreachable, nici TCP reset, doar absența unui răspuns. În funcție de producător, redirectorul poate răspunde pe portul 80 cu o redirecționare către pagina de conectare, în timp ce portul 443 e aruncat sau interceptat. Redirecționările se recunosc ușor pentru că duc un răspuns HTTP simplu; interceptarea pe 443 cere un certificat în care browserul tău va refuza să aibă încredere.

Autorizarea în sine e de obicei legată de adresa MAC a dispozitivului, uneori de IP-ul închiriat, și trăiește într-un tabel de sesiuni cu un temporizator. Conectarea creează o intrare. Regula de firewall care îți lasă traficul să treacă există doar cât există acea intrare, și de aceea toată problema revine mai târziu fără să se schimbe nimic la tine.

De ce handshake-ul VPN moare înainte să înceapă

Fiecare protocol are transportul lui, iar firewallul dinainte de autorizare le strică pe fiecare altfel. IKEv2 pe Windows și iOS merge pe UDP 500 și UDP 4500; o aruncare pe aceste porturi apare ca 809, sau ca o eșuare de tip rezolvare de nume la clienții care raportează fazele separat. OpenVPN pe UDP 1194 rămâne în stare de conectare până îi expiră timeout-ul. OpenVPN pe TCP 443 e cazul interesant, pentru că portalul poate încheia handshake-ul TCP și apoi poate răspunde cu pagina lui de redirecționare, așa că vezi o eroare TLS în loc de timeout.

WireGuard arată mecanismul cel mai clar. E doar UDP prin design, fără variantă TCP, așa că un firewall care aruncă UDP necunoscut elimină complet transportul. Clientul continuă să trimită inițieri de handshake cu o pauză crescătoare și raportează un handshake care nu se termină niciodată. Nimic din acel mesaj nu pomenește Wi-Fi și nimic nu sugerează că ar trebui să deschizi un browser.

Platformele încearcă să observe starea înaintea VPN-ului tău. Windows ia un URL cunoscut ca să decidă dacă arată notificarea de conectare, Android cere un punct final care ar trebui să răspundă 204 No Content, iar dispozitivele Apple deschid o mică fereastră de rețea captivă. Sondele acelea funcționează pentru că portalul răspunde cu o redirecționare în loc de corpul așteptat. Același comportament explică de ce un portal poate părea perfect sănătos în timp ce tunelul tău e mort: sonda și tunelul sunt judecate după reguli diferite.

Ce resetează de fapt expirarea sesiunii

Locurile expiră sesiuni din motive fără legătură cu contul tău VPN: un timeout de inactivitate, o lungime maximă a sesiunii, un lease DHCP nou sau o reasociere la alt punct de acces. Când temporizatorul se declanșează, intrarea din tabelul de sesiuni dispare, iar setul de reguli dinainte de autorizare revine exact cum era la check-in.

Un tunel stabilit supraviețuiește adesea destul de mult ca să pară sănătos. Mesajele de keepalive continuă să iasă, iar dacă clientul le observă depinde de felul în care tratează traficul fără răspuns, așa că lumina de stare poate rămâne verde o vreme după ce calea a dispărut. Apoi tunelul cade și fiecare încercare de reconectare eșuează pe aceleași porturi blocate.

În acel moment eroarea clientului îți spune în ce fază ești, dacă o citești cu atenție:

Un detaliu îi păcălește pe oameni: când sesiunea e legată de o adresă MAC, reîncărcarea paginii de conectare s-ar putea să nu ajute. Trebuie să renunți la asociere și să te alături din nou, ca portalul să vadă o încercare nouă de autorizare în loc de una expirată.

Conectează-te întâi, apoi ridică tunelul

Ordinea care funcționează este: autorizează dispozitivul, dovedește calea, pornește VPN-ul, dovedește tunelul și apoi restaurează-ți blocarea obișnuită. Ultimul pas e important pentru că starea temporară de care ai nevoie ca să ajungi la portal e exact starea pe care un kill switch există ca să o împiedice.

Un client de desktop cu opțiunea de blocare în afara tunelului trebuie pus pe pauză ca pagina portalului să se încarce, iar aplicațiile sensibile ar trebui ținute închise în acea fereastră din afara tunelului; e singurul interval în care traficul local iese fără protecție. Un dispozitiv administrat, mereu pornit, ar trebui să folosească procedura publicată de proprietar în loc să fii tu cel care scoate politica. Dacă portalul arată un avertisment de certificat, oprește-te: acceptarea lui duce sesiunea prin proxy-ul de interceptare al locului, iar acel proxy poate citi tot ce trimiți. Pe Android, blocarea sub VPN mereu activ oprește traficul înainte ca tunelul să urce, iar unele build-uri nu pot excepta fluxul portalului; dacă al tău nu poate, folosește accesul alternativ al locului sau alt dispozitiv în loc să lași blocarea oprită. Regulile on-demand ale Apple pot fi scrise ca să refuze tunelul până reușește o sondă, și asta e comportamentul pe care îl vrei în rețelele de hotel.

Verifică în ordine cu uneltele pe care le ai deja. Înainte de tunel, rulează sonda cu antetele și corpul amândouă vizibile, și uită-te dacă transportul VPN primește vreun răspuns:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Înainte de autorizare, un portal normal dă unul din două răspunsuri: un 302 al cărui Location indică pagina de conectare, sau un 200 cu un corp HTML care e pagina portalului. Notează pe care l-ai primit. O redirecționare nu e o eșuare înainte de conectare; portalul îți spune încotro să mergi. După ce portalul raportează succes, repetă comanda și așteaptă un 200 al cărui corp e cuvântul literal Success. Acel șir face sonda semnificativă. Dacă gazda răspunde normal înainte să te fi conectat vreodată, nu există portal de interceptare în această rețea. În captură, o aruncare dinainte de autorizare e pachete de ieșire din care nu se întoarce nimic, în timp ce o cale care funcționează arată un răspuns pe același flux în circa o secundă. Conectează-te și apoi repetă captura.

Dacă tunelul tot eșuează după ce portalul spune da

Succesul conectării nu e același lucru cu transportul permis. Multe locuri permit portalul și navigarea obișnuită, dar blochează complet UDP, ceea ce lasă WireGuard și OpenVPN pe UDP stricate și TCP 443 funcțional. Dacă TCP 443 trece și UDP nu, e politica locului și nu un client configurat greșit de tine, așa că schimbă transportul sau acceptă limita și mergi mai departe. Dacă o reconectare tot eșuează după asta, păstrează eroarea exactă; ea numește faza în care ești blocat.

Alte eșuări trăiesc pe dispozitiv. O sesiune încă legată de un MAC vechi, un al doilea adaptor Wi-Fi cu lease-ul lui, sau un client care a pus în cache excepția de certificat a portalului pot fiecare continua să eșueze după o reautorizare curată. Renunță la asociere, autorizează din nou și încearcă o dată înainte să atingi setările clientului. RFC 8952 merită citit dacă vrei arhitectura din spatele componentelor pe care le observi.

Dacă portalul însuși refuză să autorizeze, problema e la cont sau la alocarea dispozitivului și nicio setare VPN nu o repară. Schimbarea țării de ieșire a VPN-ului nu resetează starea de acces locală a locului; acel tabel e legat de dispozitivul tău, nu de serverul pe care îl alegi. Întreabă operatorul locului și dă-i timp, pentru că tabelul de sesiuni e ceea ce se va uita.

Înainte de următoarea călătorie notează trei lucruri: pagina portalului ca pas zero, pasul de pauză a blocării pentru fiecare dispozitiv pe care îl iei, și un transport de rezervă pe care l-ai testat cu adevărat. Când un tunel care funcționa acum zece minute se oprește din nou, tratează-l ca pe o autorizare expirată și verifică portalul din nou înainte să atingi profilul VPN.