Wi-Fi în hotel: VPN-ul eșuează înainte de a ajunge la server

Clientul VPN se învârte, apoi raportează că nu poate ajunge la server, și toți concluzionează că hotelul blochează VPN-urile. De obicei nu s-a întâmplat nimic atât de dramatic: rețeaua nu te-a lăsat încă să ieși. Un portal captiv reține fiecare conexiune până te autentifici, iar un tunel nu se poate finaliza cât timp o pagină de autentificare îi interceptează pachetele. Parcurge autentificarea înainte de a da vina pe tunel.

Mitul: hotelul blochează VPN-urile

Majoritatea rețelelor de hotel nu filtrează tunelurile în mod special. Interceptează traficul web până când oaspetele se autentifică și pot limita dispozitive, expira sesiuni sau reduce debitul. Fiecare dintre acestea produce o defecțiune care, din interiorul unui client VPN, arată ca o blocare.

Tunelul este aici un instrument de diagnostic slab, pentru că este singura aplicație care eșuează sigur cât timp portalul nu este autorizat. Accesul web obișnuit este indicatorul mai bun, pentru că îți poate arăta pagina de autentificare.

Această ordine contează din alt motiv: un client cu kill switch sau mod mereu activ va refuza să încarce portalul, iar utilizatorul va concluziona că rețeaua e stricată, nu setarea. Ambele fapte sunt adevărate simultan, și doar unul poate fi schimbat la hotel. Oprește protecția din controlul propriu al clientului, autentifică-te și pornește-o la loc. Orice altceva este un ocol care ascunde ordinea reală.

Termină mai întâi portalul, apoi testează HTTPS obișnuit

Întreabă personalul despre numele oficial al rețelei și metoda de autentificare. Un SSID convingător nu este dovadă de proprietate, iar o a doua rețea cu nume similar este un truc obișnuit în locuri publice. Folosește solicitarea de autentificare a sistemului de operare unde există, sau pagina documentată a hotelului.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

Prima cerere interoghează un punct cunoscut de detectare a portalului captiv prin HTTP simplu; o redirecționare sau un corp neașteptat înseamnă că ești încă în spatele portalului. A doua testează un site HTTPS normal. Dacă prima arată interceptare și a doua eșuează, autentificarea este incompletă și VPN-ul nu are nicio legătură.

Pe un dispozitiv personal poate fi nevoie să oprești kill switch-ul sau VPN-ul mereu activ prin controlul acceptat al clientului, ca portalul să se poată încărca. Închide aplicațiile sensibile în acel interval și repornește protecția imediat după. Pe un dispozitiv administrat, urmează procedura aprobată de administrator în loc să elimini singur o politică.

Nu ocoli niciodată un avertisment de certificat și nu instala un certificat necunoscut sau o aplicație auxiliară pentru a intra online. Dacă portalul cere ceva neașteptat, confirmă cu personalul, și cu administratorul dacă dispozitivul aparține unui angajator.

Păstrează profilul original și eroarea lui

După ce accesul obișnuit funcționează, conectează profilul original și notează eroarea exactă. O respingere a autentificării este o problemă de cont, un timp de așteptare în timpul negocierii este o problemă de cale, iar un tunel care se stabilește dar nu transportă nimic este o problemă de rutare sau de politică.

Aceste trei necesită pași următori diferiți, iar o captură a erorii valorează mai mult decât o descriere. Notează și ora, pentru că limitele sesiunii de hotel pot expira într-o oră și pot produce o defecțiune care pare aleatorie. Dacă clientul oferă un jurnal, păstrează secțiunea din jurul primei defecțiuni, nu fișierul întreg. Acel fragment este de obicei suficient pentru proprietarul profilului ca să identifice etapa.

Dacă accesul obișnuit funcționează iar negocierea încă expiră, întreabă hotelul dacă acceptă acel trafic și compară cu un hotspot de încredere, ținând dispozitivul și profilul neschimbate. Lucrul pe hotspot îngustează atenția spre calea hotelului fără a dovedi nimic despre profil.

Folosește doar alternativele furnizate de operator

Un profil TCP potrivit poate reuși acolo unde calea UDP oferită nu funcționează, dar numai dacă serverul chiar ascultă pe acel transport și port. Portul TCP 443 nu este tratat automat ca HTTPS obișnuit și nu este o garanție a trecerii printr-o rețea restrictivă.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

Rularea profilului furnizat cu mai mult detaliu păstrează vizibilă prima eroare utilă în loc să o strivească într-un dialog generic de eșec. Folosește fișierul dat de operator în loc să editezi singur porturi sau protocoale, pentru că o modificare locală nu poate crea un ascultător potrivit în cealaltă parte.

Dacă tunelul se resetează repetat, notează dacă portalul reapare sau semnalul local scade, și urmează verificările de stabilitate în loc să schimbi mai multe protocoale deodată. Apoi testează aplicația de care ai cu adevărat nevoie și restaurează controalele obișnuite de confidențialitate. O conexiune care transportă un site dar nu altul este o chestiune de rutare sau de politică, nu de portal.

În final, verifică recuperarea după ce laptopul adoarme. Autorizarea portalului poate expira independent de tunel, așa că un dispozitiv care se reconectează automat poate reveni într-o rețea care l-a uitat deja. Redeschiderea paginii portalului este un pas normal, nu un semn că VPN-ul s-a stricat.