Caída horaria de OpenVPN: ¿renegociación o una reconexión real?

Sesenta minutos, o treinta, o ciento veinte: una caída que cae en un intervalo redondo casi nunca es la red. OpenVPN renueva según un temporizador el material de claves que protege el canal de datos, y un temporizador más corto que el que suponía se ve exactamente como un enlace que falla una y otra vez. Los usuarios informan de una conexión rota mientras el registro informa de un intercambio de claves correcto. La guía siguiente separa esa renovación de un reinicio real, lee el valor que realmente está en vigor y solo lo cambia después de que el coste esté sobre la mesa.

Siga los pasos en orden, porque el primero decide si el resto de la página le afecta en absoluto. Si se adelanta, pasará una tarde ajustando un temporizador por un fallo que no tiene nada que ver con él.

Distinga un reinicio suave de un reinicio

La línea del registro es todo el diagnóstico. Una renegociación escribe un reinicio suave y luego un intercambio de claves nuevo dentro del mismo túnel: la interfaz conserva su dirección, las rutas no se vuelven a añadir y las sesiones TCP establecidas suelen sobrevivir con una pausa. Un reinicio real rompe la sesión, reconstruye la interfaz, puede entregar otra dirección de cliente y mata toda conexión de larga duración. Ambos sucesos son normales; solo uno explica una llamada cortada.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

La línea de versión importa porque la redacción del registro cambia entre versiones, y un mensaje que recuerda del 2.3 puede estar redactado de otra forma en el 2.6. Lea su propio registro en vez de un extracto de foro de otra persona. Cite la línea exacta cuando pida ayuda, porque una paráfrasis pierde el detalle que identifica el suceso. Si la dirección de la interfaz no cambia durante el suceso y la lista de sesiones sobrevive, está viendo una renovación y las secciones restantes se aplican.

Lea el temporizador efectivo, no su archivo

reneg-sec es el número de segundos entre renegociaciones del canal de datos y su valor por defecto es 3600. Cada par lleva su propio valor, y el menor de los dos es el que realmente desencadena la renovación. Esa sola regla explica la mayoría de los informes: un perfil de cliente que fija un número grande sigue reiniciándose cada hora mientras el servidor mantiene el valor por defecto.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Lea también la configuración efectiva del servidor, incluido todo lo que empuja, antes de sacar conclusiones del archivo del cliente. Después suba la verbosidad y observe un intervalo de principio a fin: el nivel 3 ya muestra las líneas de renegociación, y las marcas de tiempo dicen si el suceso se repite cada 3600 segundos o sigue la actividad.

Cámbielo donde realmente se empuja

El remedio que circula es una sola línea en el perfil del cliente, y es el lugar equivocado aproximadamente la mitad de las veces. Como gana el valor más bajo de los pares, un cliente que pone el temporizador a cero todavía puede ser renegociado por un servidor que no cambió.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Cuando los perfiles se generan de forma central, edite la plantilla y no la copia desplegada, o la siguiente ejecución de aprovisionamiento restaurará el valor que acaba de quitar. Verifíquelo observando dos intervalos, no uno: una hora tranquila también encaja con un temporizador puesto a 7200.

Decida también qué ocurre en un despliegue mixto. Si extiende el cambio primero a los clientes, queda una ventana en la que el servidor todavía desencadena la renovación; es inofensivo pero confuso si mira los registros buscando confirmación. Cambie primero el lado que tiene el valor menor y el síntoma desaparece en el punto que espera.

Qué cede al desactivar la renegociación

La renegociación periódica limita cuánto tiempo un solo conjunto de claves del canal de datos protege el tráfico. Desactivar el temporizador no rompe el túnel, y en un router doméstico o una puerta de enlace de oficina pequeña la exposición práctica es modesta. Sigue siendo un intercambio, y merece la pena enunciarlo antes de hacerlo. Lo que cambia es cuánto tiempo un conjunto de claves protege una sesión, no si el túnel funciona en absoluto.

El caso razonable para desactivarlo es un reinicio que rompe algo que no puede reanudarse: una llamada que se cae, una sesión de escritorio remoto que hay que restablecer, una copia de seguridad que empieza desde el principio. Si la pausa es invisible para los usuarios, mantener el valor por defecto no cuesta nada y conserva la rotación de claves que le dieron.

Prefiera arreglar la causa cuando el patrón lo permite. Una renovación que falla a mitad de camino mientras el primer saludo tuvo éxito apunta al camino y no al temporizador: busque un problema de tamaño de paquete en el intercambio mayor del canal de control, un cortafuegos con estado que descarta el flujo o una propuesta que solo tiene éxito al primer intento. Cada uno deja un rastro en el mismo registro que acaba de leer. Desactivar el temporizador oculta esa evidencia.

Cuando el intervalo apunta a otro sitio

Dos vecinos en la configuración producen síntomas parecidos y arreglos distintos. ping-restart reinicia el túnel cuando no llega nada durante un periodo configurado, mientras que ping-exit tumba al cliente por completo. Una caída inactiva sin ninguna renegociación en el registro pertenece a estos o a un dispositivo NAT que hizo caducar la asignación UDP según su propio calendario.

Los routers de consumo, los puntos de acceso móviles y el NAT de operador hacen caducar las sesiones UDP inactivas sin avisar a nadie. Ese fallo sigue a la inactividad y no al reloj, y esa es la pista: una sesión que cae tras diez minutos tranquilos y sobrevive una hora de tráfico constante no está renegociando.

Anote tres cosas antes de cambiar una cuarta: el intervalo que midió, el valor efectivo que encontró y el comando que lo mostró. Si el intervalo se mueve cuando se mueve el temporizador, el mecanismo queda identificado y el arreglo es una decisión sobre el intercambio anterior. Si no se mueve, devuelva el ajuste y siga mirando keepalives, estado de NAT y pérdida de paquetes.