¿Se cae la VPN tras una renovación DHCP? Compare las direcciones

La renovación del arrendamiento y el fallo de la VPN aparecen juntos en los registros con la suficiente frecuencia como para que la gente concluya que uno causa el otro. La coincidencia temporal es real; la causalidad normalmente no. Una renovación es una solicitud unicast al servidor que emitió el arrendamiento, pidiendo continuar con la misma vinculación, y el servidor puede ampliarla sin que el cliente cambie una sola dirección. Revisar los valores propios del cliente alrededor del evento separa un arrendamiento renovado en silencio de una red que cambió de verdad bajo un túnel en funcionamiento.

Empiece por el cliente que se cayó

Abra primero el registro de conexión del cliente y anote la hora de la caída al segundo. Después abra el registro de red del sistema operativo para el mismo minuto y lea en orden qué hizo la interfaz. Ese orden es toda la investigación: un evento DHCP antes de la desconexión, una desconexión antes del evento DHCP y dos eventos sin nada entre ellos son tres hallazgos distintos. Una línea de registro que solo menciona el arrendamiento mientras el túnel ya se reconectaba es decoración, no prueba.

Escriba la línea temporal sobre la marcha en lugar de retenerla en la memoria. Las marcas de tiempo de herramientas distintas rara vez coinciden del todo, y el desfase mismo es a veces la explicación.

Compare los cuatro valores alrededor del evento

Cuatro valores describen el lado local de una conexión lo bastante bien como para detectar un cambio real: la dirección de la interfaz, la puerta de enlace predeterminada, la lista de resolutores y el estado operativo de la interfaz. Captúrelos dentro del minuto siguiente a la caída y compárelos con una captura tomada mientras el túnel estaba sano.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Una dirección sin cambios con una puerta de enlace sin cambios y una lista de resolutores cambiada apunta a la resolución de nombres y no al enrutamiento, y el túnel pudo sobrevivir mientras las aplicaciones dejaban de encontrar hosts. Una puerta de enlace cambiada significa que el camino de salida de la red local se movió, lo que basta para invalidar una ruta que apuntaba a la anterior. Si los cuatro valores coinciden con la captura sana, el arrendamiento no es su causa y la lógica de reconexión del propio cliente pasa a ser el tema. Capture la comparación mientras el fallo es visible, porque una captura sana tomada tras un reinicio tiene un historial de direcciones distinto y no coincidirá.

Qué puede y qué no puede cambiar una renovación

RFC 2131 describe la renovación como una solicitud al servidor original a la mitad del tiempo de arrendamiento, con revinculación a cualquier servidor a los siete octavos si el primer intento queda sin respuesta. Ninguno de los pasos exige que el cliente adquiera una dirección distinta, y un servidor cooperativo normalmente amplía la vinculación existente. Un cambio real de dirección suele llegar por otro camino: un servidor que rechaza la renovación, un cliente que perdió su estado y empezó de nuevo, o una red que movió el dispositivo a otro segmento.

El lado público de la conexión puede cambiar sin ningún cambio local. Detrás de una traducción de grado operador, la dirección que ve el par de la VPN puede reasignarse con independencia de lo que hiciera el arrendamiento local, y esa reasignación se ve idéntica a un fallo de red local desde dentro del cliente. Comparar una dirección informada localmente con una observación del lado del par es la única forma de separarlas.

Cuando el cliente no logra adaptarse

Un cliente que vinculó su transporte a la dirección antigua, almacenó una ruta obsoleta hacia el par o guardó una identidad de interfaz puede seguir reintentando un camino que ya no existe. Eso es un defecto de adaptación, y se ve como retransmisiones repetidas hacia una dirección que el host ya no puede alcanzar. Algunos clientes lo manejan por diseño: WireGuard, por ejemplo, actualiza el extremo de un par cuando llega un paquete correctamente autenticado desde una fuente nueva.

Un reinicio manual que restaura el servicio es una pista sobre dónde falló la adaptación, no una prueba de que arrendamientos y túneles sean incompatibles. Mantenga la política de bloqueo mientras prueba, o la propia prueba se convierte en una caída con otra causa. Anote si el cliente se recuperó solo, cuánto tardó y a qué dirección reintentó; esa secuencia le dice más que el motivo de desconexión que muestra la interfaz.

Repita el evento antes de culparlo

Reproduzca la condición en lugar de esperar al calendario: libere y renueve el arrendamiento, o fuerce el evento controlado equivalente, y observe si el túnel sobrevive. En una red gestionada, coordine cualquier cambio de dirección con el propietario de la red, porque una asignación estática arbitraria puede chocar con un dispositivo que ya tiene esa dirección.

Tras una corrección soportada, repita el mismo evento y luego pruebe una aplicación y una consulta de nombre, porque un túnel que se reconecta pero rompe el DNS supera una prueba más débil que la que importa. Informe del cambio concreto que observó, con su marca de tiempo, en lugar de nombrar el arrendamiento programado como causa. La diferencia entre esos dos informes es si la siguiente persona puede reproducir el fallo o solo el rumor.