¿Reiniciar OpenVPN a diario? Elija el fallo, no el reloj

Hereda una tarea cron que reinicia OpenVPN todos los días a las 04:10 y que lleva un año manteniendo las cosas estables. También desconecta un túnel sano a una hora fija y no hace nada por la caída que ocurre de verdad a la hora de comer. Un reinicio por calendario es una decisión de mantenimiento. La recuperación es un diseño distinto, con un disparador concreto.

Tres formas de fallo necesitan tres propietarios distintos. Elija primero el fallo y el mecanismo vendrá después.

Tres fallos, tres propietarios

Un túnel puede estar activo mientras su par se ha ido: el proceso se ejecuta, la interfaz existe y nada útil la atraviesa. Un proceso puede estar muerto mientras el par está bien, y entonces solo lo que lo inició puede devolverlo. Una aplicación detrás del túnel puede estar rota mientras tanto el túnel como el par están sanos, y reiniciar entonces el cliente amplía la caída sin tocar la causa. Separar esos tres casos es toda la decisión.

Cada uno tiene su propia señal y su propio propietario. La vitalidad pertenece al protocolo VPN, el ciclo de vida del proceso pertenece al gestor de servicios y la salud de la aplicación pertenece al monitoreo con un mandato estrecho.

Qué puede y qué no puede hacer una opción de vitalidad

keepalive es un auxiliar que se expande en un par ping y ping-restart, como describe la referencia de opciones de enlace, y los tiempos de espera que produce no son idénticos en el servidor y en el cliente. Los valores que empuja un servidor también pueden anular lo que un cliente configuró localmente, y por eso un tiempo de espera que parece correcto en un archivo local puede no ser el que está en vigor.

Eso lo convierte en la herramienta adecuada para un par perdido y en la herramienta equivocada para un proceso muerto, ya que un proceso terminado no puede ejecutar sus propios temporizadores. Tampoco dice nada sobre si responde una aplicación detrás del túnel, porque el intercambio ocurre entre los dos extremos del VPN. Copiar un par de tiempos de espera de otro despliegue sin comprobar el rol, las interrupciones previstas y el comportamiento de reautenticación es como un túnel estable empieza a oscilar.

Qué posee el gestor de servicios

Si el demonio termina, el gestor que lo inició decide qué pasa después. Una política de reinicio ligada al fallo, con retardo y un límite de tasa de arranque, gestiona un bucle de caídas sin convertirlo en una fork bomb. Esos ajustes responden a los resultados del proceso y a los tiempos de espera, y no detectan un proceso que está vivo pero es inútil. Eso no es un hueco que tapar con una política más amplia; es la frontera entre el ciclo de vida y la vitalidad.

La propiedad importa tanto como los ajustes. Una conexión iniciada por un gestor de red de escritorio debería conservar el arreglo de recuperación de ese gestor, y añadir una unidad de servicio competidora para la misma interfaz da dos propietarios a un solo túnel. Elija uno y deje escrito cuál es.

Cuándo es legítimo un reinicio programado

Un reinicio temporizado puede ser una acción de mantenimiento razonable: tiene un propietario, una ventana, una instancia con nombre y una vía de acceso independiente. Lo que no puede ser es una política general de fiabilidad que además desconecte a todos a una hora fija.

Si el reinicio existe para sortear una fuga conocida o un estado atascado, dígalo en la descripción de la unidad, porque si no la siguiente persona lo mantendrá para siempre.

Pruebe los casos que importan: el par desaparece mientras el proceso sigue activo, el proceso termina, un reintento necesita credenciales nuevas y el túnel vuelve mientras la aplicación sigue rota. Observe qué componente reacciona y qué estado deja atrás.

La pregunta correcta no es con qué frecuencia reiniciar, sino qué debería notar el fallo primero.