OpenVPN se cae tras una renovación DHCP: conserve la ruta del extremo

El túnel se conecta, luego una renovación del arrendamiento en el enlace de acceso lo mata, y el registro culpa a un tiempo de espera en lugar de a una ruta. Nada en la configuración de la VPN ha cambiado, y esa es la pista: algo fuera de ella sí. Un evento DHCP reescribió la dirección o la puerta de enlace, y la ruta de host que mantenía accesible el extremo del túnel ahora apunta a un siguiente salto que ya no existe. Este es un problema de propiedad antes que un problema de enrutamiento.

Compare el síntoma con las rutas medio predeterminadas

Con redirect-gateway def1, OpenVPN instala 0.0.0.0/1 y 128.0.0.0/1 en lugar de sustituir la ruta predeterminada. Juntas, esas dos cubren todo el espacio de direcciones, y vencen a 0.0.0.0/0 solo por la longitud del prefijo. Por eso cualquier destino sin una coincidencia más específica entra en el túnel.

El extremo necesita una excepción. OpenVPN añade una ruta de host hacia la dirección del servidor a través de la puerta de enlace de acceso original antes de que entren las medio predeterminadas, para que los paquetes encapsulados puedan salir. Cuando esa excepción desaparece, o conserva un siguiente salto que ya no existe, los propios paquetes exteriores del túnel coinciden con una medio predeterminada y se envían de vuelta al túnel. El resultado es una conexión que muere en el siguiente keepalive o apretón de manos, sin nada en el registro que parezca un error de enrutamiento.

Confirme la forma de la tabla antes de tocar cualquier otra cosa. ip route show debería listar ambas mitades más una ruta de host para la dirección del servidor; cuando falta la ruta de host, el resto de la investigación tiene un punto de partida obvio.

Por qué ganan las medio predeterminadas sin cambiar la métrica

Una métrica más baja no vence a un prefijo más largo. Las rutas /1 ganan porque el núcleo primero hace coincidir la ruta más específica, así que subir una métrica en la ruta predeterminada no cambia nada sobre adónde va el tráfico destinado al túnel. Perseguir métricas es el desvío más común en este diagnóstico.

Compruebe la selección con ip route get 203.0.113.10, sustituyendo la dirección real del servidor. La respuesta nombra la interfaz y el siguiente salto que el núcleo usaría realmente, lo que es más informativo que leer una tabla y razonar sobre ella.

Ejecute ese comando antes de que arranque el túnel, mientras está activo y después del evento de arrendamiento. Tres respuestas de un solo comando, y el punto de divergencia se vuelve visible.

Tome tres instantáneas, no una

Recoja la dirección de acceso, la puerta de enlace de acceso, el destino del extremo, la ruta seleccionada y cualquier regla de política en tres momentos: después de configurar el enlace de acceso, después de que se conecte la VPN y después del evento de arrendamiento o del operador. Cada instantánea es un puñado de comandos, y solo significan algo juntas. Una única instantánea posterior al fallo registra el estado en lugar de la transición. Escriba los comandos en un pequeño script para que cada instantánea se tome de la misma manera.

Guarde las instantáneas en un solo archivo con marcas de tiempo, porque la pregunta interesante después es el orden. ¿Llegó el evento DHCP antes o después de que OpenVPN refrescara su ruta? La respuesta decide quién tiene que arreglarlo. Una marca de tiempo de un reloj equivocado es peor que ninguna, así que tómela del host que posee la tabla de enrutamiento.

Cuando el extremo está configurado como un nombre en lugar de una dirección, resuélvalo también en cada instantánea. Un cambio de DNS en el enlace de acceso puede mover el extremo sin que se toque ninguna ruta.

Decida qué componente refresca la excepción

En un sistema dhcpcd, los ganchos se ejecutan desde el directorio de ganchos y desde el gancho de salida, y el modo gestor difiere en alcance del modo por interfaz. Haga lo que haga el gancho, debe ser idempotente, porque las renovaciones pueden llegar en ráfagas.

El propietario fiable es la integración que ya conoce ambos lados: un gestor de red que administra la conexión VPN, o una unidad ordenada después de que suba el enlace de acceso. Una ruta estática añadida por un gancho funciona hasta el siguiente cambio de puerta de enlace, y luego falla exactamente de la misma manera. Si usa un gancho, haga que lea la puerta de enlace actual en tiempo de ejecución en lugar de codificar la que vio hoy.

Registre el propietario dentro de la configuración. La siguiente persona que depure una reconexión necesita saber que un gancho, no la VPN, es responsable de la ruta de excepción.

Pruebe el ciclo de vida, no solo la reconexión

Fuerce una renovación con dhcpcd -n eth0 o liberando y renovando el arrendamiento, y luego compruebe ip route get de nuevo para el extremo. Hágalo dos veces, porque la segunda pasada atrapa ganchos que añaden rutas duplicadas. Luego reinicie, porque la persistencia es una propiedad distinta de la corrección.

Un túnel que sobrevive a una renovación y a un reinicio tiene propietario y una excepción que funciona. El que solo sobrevive a un reinicio manual no tiene ninguna de las dos, y fallará en el siguiente evento que no pueda programar.