Wi-Fi do hotel: a VPN falla antes de chegar ao servidor

O cliente VPN xira e logo informa de que non pode chegar ao servidor, e todos conclúen que o hotel bloquea as VPN. Normalmente non pasou nada tan dramático: a rede aínda non te deixou saír. Un portal cativo retén cada conexión ata que inicias sesión, e un túnel non pode completarse mentres unha páxina de acceso intercepta os seus paquetes. Fai o inicio de sesión antes de culpar o túnel.

O mito: o hotel bloquea as VPN

A maioría das redes de hotel non filtran túneles especificamente. Interceptan o tráfico web ata que o hóspede se autentica, e tamén poden limitar dispositivos, caducar sesións ou rebaixar o rendemento. Cada unha desas cousas produce un fallo que desde dentro dun cliente VPN parece un bloqueo.

O túnel é aquí un mal diagnóstico, porque é a única aplicación que falla con seguridade mentres o portal non está autenticado. O acceso web normal é o mellor indicador, porque pode amosarche a propia páxina de acceso.

Esa orde importa por outra razón: un cliente con interruptor de seguridade ou modo sempre activo negarase a cargar o portal, e o usuario concluirá que a rede está rota e non o axuste. Ambos os feitos son certos á vez, e só un deles pode cambiarse no hotel. Desactiva a protección co control propio do cliente, inicia sesión e volve activala. Calquera outra cousa é un rodeo que agocha a secuencia real.

Remata primeiro o portal e logo proba o HTTPS normal

Pregunta ao persoal o nome oficial da rede e o método de acceso. Un SSID convincente non é proba de propiedade, e unha segunda rede cun nome parecido é un truco habitual en lugares públicos. Usa o aviso de acceso do propio sistema operativo cando o ofreza, ou a páxina documentada do 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/

A primeira petición consulta un punto de detección de portal cativo coñecido por HTTP simple; unha redirección ou un corpo inesperado significa que segues detrás do portal. A segunda proba un sitio HTTPS normal. Se a primeira mostra intercepción e a segunda falla, o inicio de sesión está incompleto e a VPN non ten nada que ver.

Nun dispositivo persoal pode que haxa que desactivar o interruptor de seguridade ou a VPN sempre activa co control compatible do cliente para que o portal poida cargarse. Pecha as aplicacións sensibles durante ese intervalo e volve activar a protección inmediatamente despois. Nun dispositivo xestionado, segue o procedemento aprobado polo administrador en lugar de quitar unha política por ti mesmo.

Nunca omitas un aviso de certificado nin instales un certificado descoñecido ou unha aplicación auxiliar para conectarte. Se o portal esixe algo inesperado, confírmao co persoal, e co administrador se o dispositivo pertence a un empregador.

Conserva o perfil orixinal e o seu erro

Cando o acceso normal funcione, conecta o perfil orixinal e anota o erro exacto. Un rexeitamento de autenticación é un problema de conta, un tempo de espera durante a negociación é un problema de ruta, e un túnel que se establece pero non transporta nada é un problema de encamiñamento ou de política.

Eses tres precisan pasos seguintes distintos, e unha captura do erro vale máis ca unha descrición. Anota tamén a hora, porque os límites de sesión do hotel poden caducar nunha hora e producir un fallo que parece aleatorio. Se o cliente ofrece un rexistro, garda o treito arredor do primeiro fallo e non o ficheiro enteiro. Ese extracto adoita abondar a quen posúe o perfil para identificar a etapa.

Se o acceso normal funciona e a negociación segue esgotándose, pregunta ao hotel se admite ese tráfico e compara cun punto de acceso de confianza mantendo o dispositivo e o perfil constantes. Traballar no punto de acceso estreita a atención cara á ruta do hotel sen demostrar nada sobre o perfil.

Usa só as alternativas que proporcione o operador

Un perfil TCP correspondente pode ter éxito onde a ruta UDP ofrecida non funciona, pero só se o servidor escoita realmente nese transporte e porto. O porto TCP 443 non se trata automaticamente como HTTPS normal, e non é garantía de paso por unha rede restritiva.

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

Executar o perfil fornecido con maior detalle mantén visible o primeiro erro útil en lugar de fundilo nun diálogo xenérico de fallo. Usa o ficheiro que deu o operador en vez de editar portos ou protocolos por ti mesmo, porque un cambio local non pode crear un oínte correspondente no outro extremo.

Se o túnel se reinicia repetidamente, anota se o portal reaparece ou se cae o sinal local, e segue as comprobacións de estabilidade en lugar de cambiar varios protocolos á vez. Despois proba a aplicación que realmente necesitas e restaura os controls de privacidade habituais. Unha conexión que leva un sitio pero non outro é unha cuestión de encamiñamento ou de política, non do portal.

Por último, comproba a recuperación despois de que o portátil durma. A autorización do portal pode caducar de forma independente ao túnel, así que un dispositivo que se reconecta só pode volver a unha rede que xa o esqueceu. Volver abrir a páxina do portal é un paso normal, non un sinal de que a VPN estea rota.