La VPN se mudó: por qué tu cliente OpenVPN sigue marcando la IP antigua

El proveedor cambió su dirección pública, usted actualizó el registro DNS dinámico y el cliente sigue sin poder conectarse. Desde fuera parece que el registro no se propagó. La mayoría de las veces el registro está bien y el cliente marca la dirección que resolvió antes de la mudanza, porque un túnel en marcha y un perfil guardado tienen cada uno su propia idea de dónde vive el servidor. Tres capas tienen que coincidir, y se actualizan en calendarios distintos.

Mire lo que marca el perfil, no lo que dice el DNS

Abra la conexión que usa realmente y lea la línea remote. Una dirección numérica allí nunca sigue una actualización del nombre de host, por correcto que llegue a ser el registro.

Luego compruebe si el perfil que editó es el que cargó el cliente. Los perfiles importados son habituales: un administrador pudo tomar una copia hace meses y conservar su propia versión, así que el archivo de su carpeta de descargas y la entrada de la aplicación pueden discrepar. Compare el extremo en los detalles de conexión del propio cliente antes de depurar el DNS siquiera.

Dos archivos, un extremo: ese es el hallazgo habitual aquí.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Lea el siguiente intento de conexión del cliente

Reinicie la conexión con registro detallado y lea la línea donde se nombra la dirección con la que contactará. Ese valor es el que importa, no el que resolvió su navegador.

La caché del resolutor aún puede conservar la respuesta anterior, y algunas redes la guardan más tiempo del que pide el TTL del registro. Consulte el resolutor que el cliente usa realmente, no uno público que haya probado desde otro sitio.

Si el registro muestra la dirección nueva y la conexión sigue fallando, el problema se ha movido: el paquete va a algún sitio y nadie responde. Es una cuestión de escucha, cortafuegos o redirección de puertos, y está del lado del servidor, no en la ruta de resolución del cliente. Mantenga separados esos dos fallos, porque tratar un escucha inalcanzable como un problema de DNS le hace dar dos veces la misma vuelta.

Sepa qué reinicio está haciendo

No todos los reinicios conservan el mismo estado, y por eso un cambio de dirección puede comportarse de forma distinta según cómo se recicle el proceso. Un reinicio suave provocado por una señal conserva más contexto de la sesión anterior, mientras que una parada y arranque completos vuelven a empezar desde la configuración. Si está probando si el cliente vuelve a resolver, quiere la ruta que parte de la configuración.

Los ajustes de persistencia también importan, porque están pensados para conservar lo que se autenticó, no para perseguir direcciones nuevas.

La prueba más limpia es un arranque nuevo desde el perfil previsto, seguido de un vistazo a la línea de registro que nombra el extremo. Todo lo que aprenda de una sesión conservada en parte es una afirmación sobre esa sesión.

Las cuatro opciones y sus tareas separadas

remote con un nombre de host es el ajuste que hace posible la resolución repetida; una dirección literal en esa línea lo excluye. resolv-retry controla qué ocurre cuando falla una consulta, y la 2.6 ya lo pone en infinito por defecto. Añadirlo, por tanto, no cambia nada, y nunca programa una comprobación periódica de otra respuesta. Quien dice que sondea direcciones nuevas ha confundido la recuperación con la frescura.

persist-remote-ip trata de continuidad, no de frescura: reutiliza el extremo que se autenticó por última vez, a través de los reinicios suaves que admite. Mientras prueba una mudanza, eso es lo contrario de lo que quiere. Desactívelo para la prueba si su compilación lo activa, y restáurelo cuando el nuevo extremo esté probado. Si lo deja activo, una reconexión correcta puede no decirle nada sobre el DNS.

float acepta un par autenticado cuya dirección cambió a mitad de sesión, y solo en configuraciones que lo admiten. No refresca el DNS y no seguirá un cambio de proveedor por sí solo. Trátelo como una función de resistencia para pares que se desplazan, no como un mecanismo de direcciones dinámicas para servidores.

Confirme el extremo nuevo antes de culpar al cliente

Desde fuera de su red, compruebe que la dirección nueva tiene un escucha en el puerto configurado y que el reenvío del proveedor apunta a ella. Un registro A correcto para una máquina sin puerto abierto produce exactamente el síntoma que la gente atribuye a la caché.

Después reconecte y verifique dos cosas: que el cliente se autenticó contra el certificado de servidor esperado y que la sesión alcanza el recurso que pretendía. Un cambio de dirección no rebaja los requisitos de identidad, y una conexión que tiene éxito hacia el extremo equivocado es peor que una que falla. El manual de OpenVPN 2.6 enumera las cuatro opciones con su propio alcance, y esa es la lista de comprobación que conviene tener junto al perfil.

Mantenga una vía fuera de banda hacia el servidor antes de reiniciar el túnel que lleva su acceso administrativo. Esa sola precaución evita la mayoría de los incidentes que produce este escenario.