Un túnel que muere cada quince minutos, o cada hora en el mismo minuto, le dice que ha expirado algún temporizador, no que la red sea inestable. El movimiento útil es anotar el intervalo y compararlo con los cuatro temporizadores que producen este patrón. Cambiar los tiempos de espera antes de esa comparación suele mover el fallo sin explicarlo, lo que hace que la próxima ocurrencia sea más difícil de leer que la primera. La medición cuesta diez minutos y sustituye una semana de conjeturas.

Convierta el intervalo en un número

Recoja cinco o seis ocurrencias y calcule el hueco entre ellas, no el hueco desde el inicio del día. Una caída a las 09:12, 10:12 y 11:12 es un límite horario; una caída a las 09:12, 09:27 y 09:42 son quince minutos desde la última conexión correcta. Redondee el resultado al temporizador más plausible, no al minuto más cercano.

Registre dos momentos por evento: cuándo se movió el tráfico por última vez y cuándo el cliente informó de la desconexión. Difieren cuando un túnel muere en silencio y el cliente solo lo nota en el siguiente envío, y esa diferencia es lo que separa un tiempo de espera por inactividad de un fallo duro. Un cliente que nota tarde infla la ventana de inactividad que usted mide.

Fíjese en si la reconexión es automática. Un cliente que se reconecta en segundos mantiene el intervalo visible en el registro y fuera del informe del usuario, y por eso estos fallos suelen describirse como ocasionales y no periódicos. También oculta el evento a la persona que usa el portátil.

Cuatro temporizadores que se parecen

Casi toda caída repetida del túnel proviene de uno de estos: una renovación de claves del protocolo, una caducidad de mapeo inactivo, un evento de DHCP o de interfaz, o una política de cuenta. Se diferencian en si había tráfico y en lo que dice el registro en el límite.

Las firmas siguientes merecen aprenderse, porque permiten descartar tres explicaciones con una sola línea de registro:

TimerTypical triggerWhat the log shows at the boundary
Protocol rekeyTraffic present, fixed intervalNegotiation lines, sometimes a failure
NAT or firewall idleNo traffic for minutesSilence, then a timeout on send
DHCP lease or link changeHalf the lease, or a radio eventAddress or interface churn
Account session limitWall-clock hours since loginClean disconnect, server-side reason

La primera fila es un mecanismo de seguridad que hace su trabajo, y la segunda es un dispositivo intermedio que olvida el estado. Confundirlos lleva a debilitar la renovación o a perseguir una regla de cortafuegos que nunca estuvo implicada.

Ocupado frente a inactivo le dice qué mitad

Haga una comparación controlada con tráfico continuo, como un flujo largo hacia un host dentro del túnel, y observe si el intervalo cambia. Si la caída desaparece mientras fluyen los datos, el temporizador se basa en la inactividad.

Si sobrevive al tráfico continuo, el disparador pertenece a la renovación, la concesión o la política. Esa única prueba elimina la mitad de los candidatos en aproximadamente una hora de observación, y no cuesta nada más que atención.

Mantenga la red de acceso sin cambios durante la prueba. Pasar entre Wi-Fi y Ethernet a mitad de la comparación introduce exactamente el evento de interfaz que intenta distinguir de un temporizador.

Iguale la línea de registro con el límite

Lea los registros del cliente y del servidor alrededor del momento anotado, no el archivo completo. Una renovación muestra negociación; una caducidad por inactividad no muestra nada hasta el siguiente paquete; un cambio de concesión muestra trabajo de dirección; un límite de política suele mostrar una desconexión administrativa limpia.

Estos comandos extraen la ventana relevante de cada fuente:

grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg show

Si las tres fuentes coinciden en la marca de tiempo, tiene al dueño del temporizador. Si solo el registro del cliente tiene algo, probablemente el servidor no sea el que termina la sesión.

Arregle la etapa, no el icono

Cada dueño tiene una reparación admitida. Un fallo de renovación necesita propuestas compatibles en ambos extremos. Una caducidad por inactividad necesita una señal de mantenimiento o una expectativa de inactividad más corta, dentro de lo que permite la ruta. Un evento de concesión necesita que se ajusten la interfaz o los parámetros de energía. Un límite de cuenta es una decisión de política, no un error.

Desactivar la renovación o la autenticación para mantener el icono verde cambia una caída visible por una debilidad invisible, y le deja sin poder decir cuándo el túnel negoció claves nuevas por última vez. Vuelva a probar la duración original después y conserve las marcas de tiempo, para que el próximo evento se pueda comparar con este en lugar de empezar de cero.

Artículos relacionados