Wi-Fi de l'hotel: la VPN falla abans d'arribar al servidor

El client VPN gira i després informa que no pot arribar al servidor, i tothom conclou que l'hotel bloqueja les VPN. Normalment no ha passat res tan dramàtic: la xarxa encara no t'ha deixat sortir. Un portal captiu reté cada connexió fins que inicies la sessió, i un túnel no es pot completar mentre una pàgina d'accés intercepta els seus paquets. Fes l'entrada abans de culpar el túnel.

El mite: l'hotel bloqueja les VPN

La majoria de xarxes hoteleres no filtren túnels específicament. Intercepten el trànsit web fins que l'hoste s'autentica, i també poden limitar dispositius, fer caducar sessions o reduir l'amplada de banda. Cadascuna d'aquestes coses produeix una fallada que, des de dins d'un client VPN, sembla un bloqueig.

El túnel és aquí un mal diagnòstic, perquè és l'única aplicació que falla segur mentre el portal no està autenticat. L'accés web normal és un indicador millor, perquè et pot mostrar la mateixa pàgina d'accés.

Aquest ordre importa per una altra raó: un client amb interruptor de seguretat o mode sempre actiu es negarà a carregar el portal, i l'usuari conclourà que la xarxa està trencada i no el paràmetre. Tots dos fets són certs alhora, i només un es pot canviar a l'hotel. Desactiva la protecció amb el control propi del client, inicia la sessió i torna-la a activar. Qualsevol altra cosa és una volta que amaga la seqüència real.

Acaba primer el portal i després prova l'HTTPS normal

Demana al personal el nom oficial de la xarxa i el mètode d'accés. Un SSID convincent no és prova de propietat, i una segona xarxa amb un nom semblant és un parany habitual en llocs públics. Fes servir l'indicador d'accés del sistema operatiu quan n'ofereixi un, o la pàgina documentada de l'hotel.

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/

La primera petició consulta un punt de detecció de portal captiu conegut per HTTP pla; una redirecció o un cos inesperat vol dir que encara ets darrere del portal. La segona prova un lloc HTTPS normal. Si la primera mostra intercepció i la segona falla, l'entrada és incompleta i la VPN no hi té res a veure.

En un dispositiu personal pot caldre desactivar l'interruptor de seguretat o la VPN sempre activa amb el control compatible del client perquè el portal es pugui carregar. Tanca les aplicacions sensibles durant aquesta estona i torna a activar la protecció immediatament després. En un dispositiu gestionat, segueix el procediment aprovat per l'administrador en lloc de treure una política pel teu compte.

No saltis mai un avís de certificat ni instal·lis un certificat desconegut o una aplicació auxiliar per connectar-te. Si el portal demana alguna cosa inesperada, confirma-ho amb el personal, i amb l'administrador si el dispositiu és d'una empresa.

Conserva el perfil original i el seu error

Quan l'accés normal funcioni, connecta el perfil original i anota l'error exacte. Un rebuig d'autenticació és un problema de compte, un temps d'espera durant la negociació és un problema de camí, i un túnel que s'estableix però no transporta res és un problema d'encaminament o de política.

Aquests tres necessiten passos diferents, i una captura de l'error val més que una descripció. Anota també l'hora, perquè els límits de sessió de l'hotel poden caducar en una hora i produir una fallada que sembla aleatòria. Si el client ofereix un registre, guarda el tram al voltant de la primera fallada i no el fitxer sencer. Aquest extracte sol bastar a qui posseeix el perfil per identificar l'etapa.

Si l'accés normal funciona i la negociació encara expira, pregunta a l'hotel si admet aquest trànsit i compara amb un punt d'accés de confiança mantenint el dispositiu i el perfil constants. Treballar al punt d'accés estreny l'atenció cap al camí de l'hotel sense demostrar res sobre el perfil.

Usa només les alternatives que proporciona l'operador

Un perfil TCP corresponent pot tenir èxit on el camí UDP ofert no funciona, però només si el servidor escolta realment en aquest transport i port. El port TCP 443 no es tracta automàticament com a HTTPS normal, i no és cap garantia de pas per una xarxa restrictiva.

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

Executar el perfil subministrat amb més verbositat manté visible el primer error útil en lloc d'empassar-lo en un diàleg genèric de fallada. Fes servir el fitxer que ha donat l'operador en comptes d'editar ports o protocols pel teu compte, perquè un canvi local no pot crear un oient corresponent a l'altre costat.

Si el túnel es reinicia repetidament, fixa't si el portal torna a aparèixer o si cau el senyal local, i segueix les comprovacions d'estabilitat en lloc de canviar diversos protocols alhora. Després prova l'aplicació que realment necessites i restaura els controls de privadesa habituals. Una connexió que porta un lloc però no un altre és una qüestió d'encaminament o de política, no del portal.

Finalment, comprova la recuperació després que l'ordinador portàtil dormi. L'autorització del portal pot caducar independentment del túnel, així que un dispositiu que es reconnecta sol pot tornar a una xarxa que ja l'ha oblidat. Tornar a obrir la pàgina del portal és un pas normal, no un senyal que la VPN estigui trencada.