Wi-Fi del hotel: la VPN falla antes de llegar al servidor

El cliente VPN gira y luego informa de que no puede alcanzar el servidor, y todos concluyen que el hotel bloquea las VPN. Normalmente no ha pasado nada tan dramático: la red todavía no te ha dejado salir. Un portal cautivo retiene cada conexión hasta que inicias sesión, y un túnel no puede completarse mientras una página de acceso intercepta sus paquetes. Recorre el inicio de sesión antes de culpar al túnel.

El mito: el hotel bloquea las VPN

La mayoría de las redes de hotel no filtran túneles específicamente. Interceptan el tráfico web hasta que el huésped se autentica, y también pueden limitar dispositivos, caducar sesiones o limitar el rendimiento. Cada una de esas cosas produce un fallo que desde dentro de un cliente VPN parece un bloqueo.

El túnel es aquí un mal diagnóstico, porque es la única aplicación que falla con seguridad mientras el portal no está autenticado. El acceso web normal es el mejor indicador, porque puede mostrarte la propia página de acceso.

Ese orden importa por otra razón: un cliente con interruptor de seguridad o modo siempre activo se negará a cargar el portal, y el usuario concluirá que la red está rota y no el ajuste. Ambos hechos son ciertos a la vez, y solo uno de ellos puede cambiarse en el hotel. Desactiva la protección con el control propio del cliente, inicia sesión y vuelve a activarla. Cualquier otra cosa es un rodeo que oculta la secuencia real.

Termina primero el portal y luego prueba el HTTPS normal

Pregunta al personal el nombre oficial de la red y el método de acceso. Un SSID convincente no es prueba de propiedad, y una segunda red con un nombre parecido es un truco habitual en lugares públicos. Usa el aviso de acceso del propio sistema operativo cuando lo ofrezca, o la página documentada del 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ón consulta un punto de detección de portal cautivo conocido por HTTP simple; una redirección o un cuerpo inesperado significa que sigues detrás del portal. La segunda prueba un sitio HTTPS normal. Si la primera muestra intercepción y la segunda falla, el inicio de sesión está incompleto y la VPN no tiene nada que ver.

En un dispositivo personal puede que haya que desactivar el interruptor de seguridad o la VPN siempre activa con el control compatible del cliente para que el portal pueda cargarse. Cierra las aplicaciones sensibles durante ese intervalo y vuelve a activar la protección inmediatamente después. En un dispositivo gestionado, sigue el procedimiento aprobado por el administrador en lugar de quitar una política por tu cuenta.

Nunca omitas un aviso de certificado ni instales un certificado desconocido o una aplicación auxiliar para conectarte. Si el portal exige algo inesperado, confírmalo con el personal, y con el administrador si el dispositivo pertenece a un empleador.

Conserva el perfil original y su error

Cuando el acceso normal funcione, conecta el perfil original y anota el error exacto. Un rechazo de autenticación es un problema de cuenta, un tiempo de espera durante la negociación es un problema de ruta, y un túnel que se establece pero no transporta nada es un problema de enrutamiento o de política.

Esos tres necesitan pasos siguientes distintos, y una captura del error vale más que una descripción. Anota también la hora, porque los límites de sesión del hotel pueden caducar en una hora y producir un fallo que parece aleatorio. Si el cliente ofrece un registro, guarda el tramo alrededor del primer fallo y no el archivo entero. Ese extracto suele bastar a quien posee el perfil para identificar la etapa.

Si el acceso normal funciona y la negociación sigue agotándose, pregunta al hotel si admite ese tráfico y compara con un punto de acceso de confianza manteniendo el dispositivo y el perfil constantes. Trabajar en el punto de acceso estrecha la atención hacia la ruta del hotel sin demostrar nada sobre el perfil.

Usa solo las alternativas que proporcione el operador

Un perfil TCP correspondiente puede tener éxito donde la ruta UDP ofrecida no funciona, pero solo si el servidor escucha realmente en ese transporte y puerto. El puerto TCP 443 no se trata automáticamente como HTTPS normal, y no es garantía de paso por una red restrictiva.

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

Ejecutar el perfil proporcionado con mayor detalle mantiene visible el primer error útil en lugar de fundirlo en un diálogo genérico de fallo. Usa el archivo que dio el operador en vez de editar puertos o protocolos por tu cuenta, porque un cambio local no puede crear un oyente correspondiente en el otro extremo.

Si el túnel se reinicia repetidamente, anota si el portal reaparece o si cae la señal local, y sigue las comprobaciones de estabilidad en lugar de cambiar varios protocolos a la vez. Después prueba la aplicación que realmente necesitas y restaura los controles de privacidad habituales. Una conexión que lleva un sitio pero no otro es una cuestión de enrutamiento o de política, no del portal.

Por último, comprueba la recuperación después de que el portátil entre en reposo. La autorización del portal puede caducar de forma independiente al túnel, así que un dispositivo que se reconecta solo puede volver a una red que ya lo ha olvidado. Volver a abrir la página del portal es un paso normal, no una señal de que la VPN esté rota.