keepalive de OpenVPN o reinicio de systemd: ¿qué recupera el túnel?

Tres cosas distintas pueden fallar en un túnel, y exigen tres reacciones distintas. El par deja de responder, el proceso del demonio muere o la aplicación detrás del túnel deja de servir. Una configuración que reinicia el servicio ante cualquiera de ellas no es una supervisión cuidadosa; es una acción contundente aplicada a fallos no relacionados. Comparar qué puede observar realmente cada mecanismo hace evidente el reparto del trabajo.

Tres fallos que parecen uno

El silencio del par significa que el otro extremo dejó de enviar, y OpenVPN puede detectarlo por sí mismo porque posee el latido. La muerte del proceso significa que el demonio salió, lo que el gestor de servicios nota y OpenVPN no puede. El fallo de la aplicación significa que el túnel está bien y algo detrás no lo está, y ninguno de los otros dos mecanismos tiene forma de saberlo. Cada uno necesita una reacción distinta, y ninguno es lo mismo que advertir que el túnel está activo.

Son señales distintas de capas distintas, y cada una tiene un dueño que puede actuar sobre ella sin adivinar. Mezclarlas produce un sistema que reinicia ante síntomas que no puede interpretar.

Escriba los tres casos antes de cambiar cualquier temporizador. La lista misma suele mostrar que se le pide a un mecanismo que cubra los tres.

A qué se expande realmente keepalive

La directiva keepalive es una abreviatura, y la expansión varía según el modo. En un servidor, keepalive 10 60 se convierte en un ping local cada diez segundos, un tiempo de espera de reinicio local de 120 segundos y valores de 10 y 60 enviados a los clientes. El tiempo de espera del servidor se duplica a propósito para que un cliente tenga ocasión de reiniciar antes de que el servidor se rinda. Lea la forma expandida en la configuración en ejecución, no la abreviatura del perfil.

Esa duplicación es la razón por la que cualquier descripción que afirme que ambos extremos reinician a los sesenta segundos es incorrecta. También explica por qué los dos extremos no oscilan a la vez cuando un camino se degrada.

El latido es tráfico de pares de OpenVPN, no una sonda ICMP a algún host público. Una respuesta solo demuestra que el extremo lejano del túnel está vivo. No dice nada sobre la base de datos o el servicio web que el usuario necesita de verdad.

Lo que Restart=on-failure no vigila

Lea la unidad instalada antes de añadir una anulación. Restart=on-failure responde a condiciones documentadas de fallo del proceso, lo que no es lo mismo que vigilar el estado de la conexión. No se dispara porque haya comenzado una reconexión interna, y una salida limpia tiene una semántica distinta de una caída.

Esa distinción importa porque un reinicio interno mantiene vivo el mismo proceso. La unidad no ve nada, el túnel se recupera solo, y ese es el resultado correcto.

Fije RestartSec y los límites de arranque a propósito, o un bucle de caídas golpeará la pasarela y enterrará el error real bajo mensajes de reinicio. Un límite de reinicio que se activa deja la unidad en estado de fallo, lo cual es visible, mientras que un bucle ilimitado no lo es.

ping-restart y ping-exit no son intercambiables

ping-restart desencadena el reinicio interno de OpenVPN y conserva el proceso. ping-exit termina el proceso con el mismo tipo de tiempo de espera, lo que entrega la decisión al gestor de servicios. Son mutuamente excluyentes, y elegir el segundo cambia quién posee la recuperación. La diferencia es quién decide reintentar y cuánto estado sobrevive al intento.

Si elige salir al agotarse el tiempo, la unidad necesita una política de reinicio y un tratamiento del estado de salida que encajen, o un fallo de vitalidad parecerá una parada permanente. Las opciones de persistencia también pueden conservar interfaces y rutas durante un reinicio interno, pero no durante una salida del proceso.

Elija un ciclo de vida por despliegue y escriba por qué. Un perfil que lleva ambas directivas es un perfil que no ha decidido.

Pruebe cada fallo como su propio caso

Simule un par silencioso, un demonio asesinado y una aplicación no disponible en una ventana aprobada, y luego compruebe qué recuperación se disparó. Un par silencioso debería producir una reconexión interna, un proceso asesinado un reinicio de la unidad, y una caída de la aplicación ninguna de las dos. Cuando dos casos producen la misma acción, la propiedad sigue mezclada.

La recuperación repetida tampoco es una reparación. Las credenciales rechazadas o dos clientes que comparten un nombre efectivo seguirán sustituyéndose, y los temporizadores más rápidos solo hacen más rápida esa oscilación.