Por qué un perfil de OpenVPN funciona en casa pero falla en un hotel

El Wi-Fi de la oficina y una habitación de hotel pueden dar al mismo portátil dos redes muy distintas, y el perfil de en medio no tiene ni idea. Lo que funciona en casa presupone un enlace ascendente permisivo, una resolución de nombres que funcione y una subred local que no choque con nada de lo que transporta el túnel. Cada una de esas suposiciones puede fallar por separado.

La forma útil de depurar esto es tratar la red como cuatro hechos separados y luego probarlos en orden. Adivinar el perfil primero suele producir un cambio que no arregla nada y oscurece las pruebas.

Cuatro hechos de red cambian entre ubicaciones

El primer hecho es si la red local te deja salir siquiera. Un portal cautivo admite un dispositivo en una página de inicio de sesión y bloquea todo lo demás hasta que esa página se completa, lo que significa que el túnel no puede arrancar por correcto que sea el perfil.

El segundo es la resolución de nombres. Un portal que intercepta DNS responde a cada consulta con su propia dirección, de modo que el nombre de host de la VPN se resuelve al portal y el cliente intenta construir un túnel hacia una página web.

El tercero es el filtrado de transporte. Las redes que quieren permitir solo la navegación dejan pasar TCP 443 hacia destinos arbitrarios y descartan casi todo lo demás, incluido UDP.

El cuarto es el direccionamiento. La subred local puede superponerse con una red detrás del túnel, o el enlace ascendente puede no ofrecer ninguna ruta IPv4 utilizable.

Resolución de nombres y portal cautivo

Sustituya el nombre de host del perfil por la dirección numérica del servidor y vuelva a intentarlo. Si la IP conecta y el nombre no, la culpa es de la resolución, y el perfil en sí está bien.

Abra un navegador e intente una página HTTP normal antes de tocar la VPN. Una redirección a una página de inicio de sesión significa que el portal sigue pendiente; complételo y vuelva a conectar. Muchos hoteles también caducan la sesión a las pocas horas, lo que parece una desconexión a mediodía más que un problema de inicio de sesión.

Si la dirección numérica también falla, la resolución no es la explicación, así que pase al transporte. Guarde la dirección que probó, porque le dice a la siguiente comprobación si los paquetes salieron siquiera de la máquina.

Filtrado de transporte: primero UDP, TCP 443 como alternativa

Un flujo de OpenVPN sobre UDP 1194 no se parece a nada que reconozca un cortafuegos de hotel, así que se descarta sin error. El cliente reintenta hasta que expira su tiempo de espera, y el usuario ve una conexión que nunca se establece en lugar de un rechazo. Los cortafuegos que se comportan así rara vez registran el descarte en un lugar visible. La ausencia de un rechazo es en sí misma la pista.

TCP 443 es la alternativa fiable porque la red no puede distinguirlo de un HTTPS normal. Use el perfil TCP del operador cuando exista, ya que el servidor también debe escuchar en ese transporte y puerto; cambiar solo el cliente produce otro tipo de fallo. Si no existe ningún perfil TCP, pregunte al operador en lugar de inventarse uno editando el puerto. El lado del servidor tiene que aceptar, y un desajuste vuelve a parecer un problema de cortafuegos.

Espere un coste de rendimiento. TCP dentro de TCP amplifica las retransmisiones en un enlace con pérdidas, así que un túnel TCP que funciona puede seguir sintiéndose lento en una red de hotel congestionada. Es un intercambio por alcanzabilidad, no un fallo que perseguir.

Colisiones de direcciones y enlaces sin IPv4

Un túnel puede establecerse y no transportar nada. Cuando la LAN local y una red remota comparten un prefijo como 192.168.1.0/24, el cliente considera que el host remoto está conectado directamente y envía el paquete al enlace local en lugar del túnel. El síntoma es una conexión correcta con una subred inalcanzable, que se lee fácilmente como un problema de ruta en el lado del servidor.

La solución permanente es mover la LAN remota a un rango privado poco habitual. Elegir un rango que nadie use en casa, como 10.42.0.0/24, evita el problema para cada ubicación futura en vez de para una. El apaño local es evitar ese hotel, punto de acceso o router, que no es ninguna solución.

Los enlaces móviles añaden dos variantes. El NAT de nivel de operador significa que las conexiones entrantes no llegan, lo que importa si alojas un servidor pero no para un cliente saliente. Un APN configurado solo con IPv6 y traducción NAT64 puede hacer fallar a un cliente que exige una ruta IPv4 real, y el remedio habitual es cambiar el protocolo del APN a IPv4 o a pila doble.

Síntomas después de que el túnel esté levantado

Un túnel que conecta y luego se queda callado suele ser un problema de keepalive o de MTU, no un puerto bloqueado. Una conexión que cae tras un número fijo de minutos apunta a un temporizador de keepalive o de renegociación. Configure el cliente para sondear a su par y reiniciarse cuando las respuestas se detengan, y pruebe una MTU de túnel menor si los ping funcionan mientras las transferencias grandes se atascan.

Antes de pedir ayuda, anote tres cosas: la dirección que probó y si respondió, el transporte y el puerto que usó, y la subred local de la red que falló. Juntas separan la resolución de nombres del filtrado de transporte y de una colisión de direcciones, que son las causas que sobreviven al contacto con las pruebas.