¿OpenVPN no conecta en el Wi-Fi del hotel? Pruebe TCP 443

Abra el cliente, pulse Connect y lea la línea de estado en lugar del cuadro de diálogo que la sigue. Un perfil que se atasca en Connecting o Waiting for server tras una red de hotel, campus o móvil normalmente ha perdido su transporte en algún punto del camino, no sus credenciales. El siguiente paso útil es averiguar qué transporta esa red antes de tocar el servidor. No cambie nada hasta que el mismo perfil haya funcionado en otro sitio.

Pruebe primero desde un punto de acceso del móvil. Si el túnel se levanta allí, el servidor, el certificado y la cuenta están bien, y la única variable que queda es la red que tiene delante.

Empiece por el cliente: lea la línea de estado

La línea de estado dice qué etapa falló. Un cliente atascado en Connecting todavía resuelve el host o abre el socket exterior; uno que llega a Waiting for server tiene camino pero ninguna respuesta; uno que se autentica y luego cae tiene un problema completamente distinto. El registro del cliente y los propios campos remote y proto del perfil muestran qué intenta hacer el cliente, y --verb 4 en un cliente de línea de comandos imprime el mismo detalle. Compararlo con la red que tiene delante es lo que convierte «la VPN está bloqueada» en una afirmación concreta.

Después sondee la red con herramientas que ya tiene. nc -vzu 203.0.113.10 1194 envía un datagrama UDP, curl -v telnet://203.0.113.10:443 informa de si se completa un handshake TCP, y un navegador que carga una página HTTPS solo demuestra que el 443 de salida llega a ese único host. Las sondas pequeñas responden lo que el cliente VPN no puede: qué puerto y qué protocolo salen de esta red.

Tres comportamientos de red se parecen desde el cliente y necesitan respuestas distintas. El 443 de salida puede estar abierto, puede permitirse solo un proxy, o el 443 puede reenviarse de forma transparente a una caja de inspección que no puede leer lo que transporta. El primero se corrige con el cambio de perfil de abajo, el segundo con la configuración del proxy, y el tercero puede completar un handshake y luego atascarse cuando el inspector decide que no le gusta el flujo. Saber cuál tiene delante es la diferencia entre un cambio de diez minutos y una tarde reinstalando clientes.

Mueva el listener y el perfil a la vez

Del lado del servidor, ajuste el listener a lo que la red permite: port 443 y proto tcp en la configuración del servidor, luego reinicie el servicio y confirme el socket con ss -lntp. Del lado del cliente, el perfil debe coincidir, porque el transporte y el puerto quedan fuera del túnel: proto tcp y port 443 en el .ovpn, o los campos correspondientes en la pantalla de ajustes de la aplicación. Un perfil que sigue apuntando a UDP 1194 falla exactamente como antes, y la tentación es culpar a un cortafuegos que ya está arreglado. Si el mismo host también responde HTTPS en el 443, los dos listeners no pueden compartir esa dirección y protocolo; dé a la VPN una segunda dirección o ponga un demultiplexor delante.

Siga la primera conexión con tcpdump -ni any port 443 en ambos extremos. Los paquetes que salen del cliente y nunca llegan significan que la red filtra después de todo, o que la dirección del perfil no es la que supone. Los paquetes que llegan sin respuesta le devuelven al registro del servidor, donde una discrepancia de protocolo se ve de inmediato como un paquete descartado.

Cuando solo un proxy sale de la red

Algunas redes de invitados no permiten más que un proxy HTTP, lo que es una restricción distinta de un puerto cerrado y descarta más que OpenVPN. Los clientes que solo hablan PPTP, L2TP/IPsec o IPsec desnudo no tienen forma de pasar por uno, porque esos diseños esperan que su protocolo exterior llegue directamente al servidor. OpenVPN sí puede, con http-proxy proxy.example.net 8080 en el perfil del cliente, siempre que el proxy permita el método CONNECT a su puerto. Un proxy SOCKS es aún más fácil, porque reenvía el flujo sin importarle qué hay dentro.

Cuando el cliente no tiene soporte de proxy, un túnel SSH sobre 443 suele ser lo que queda. Añade una segunda capa, y el operador de la red puede tener una opinión al respecto, así que trátelo como un puente para un solo viaje y no como una arquitectura.

Calcule el coste del recurso antes de quedárselo

TCP dentro de TCP tiene un coste conocido. Cuando la conexión exterior es TCP y la carga útil también, un segmento perdido provoca retransmisión en las dos capas, y la conexión interior retrocede ante una pérdida que no puede ver. La navegación lo sobrelleva; las sesiones interactivas y las llamadas lo notan. Mantenga el listener TCP 443 como recurso para las redes que lo exigen, y deje UDP como opción por defecto para todo lo que aún lo deja pasar.

Anote la elección en el nombre del perfil y en las notas de soporte: qué puerto, qué protocolo y qué red la provocó. Luego pregunte al administrador de la red si ese puerto sigue abierto tras la próxima renovación del equipo, porque un recurso que desaparece en silencio es peor que no tener ninguno.