Qué sobreviven realmente persist-tun y persist-key en OpenVPN

Detener el servicio elimina la interfaz incluso con persist-tun definido. Esa es la opción funcionando tal como está documentada, no un fallo. La opción describe una ruta de reinicio dentro de un proceso en ejecución, y systemctl stop no es esa ruta.

Lea los dos nombres juntos y el diseño queda claro. Uno conserva un descriptor, el otro conserva material de clave, y ambos existen por lo que ocurre después de soltar los privilegios.

Los dos recursos y el reinicio al que pertenecen

OpenVPN señala su propio reinicio en dos situaciones habituales. Un SIGUSR1 explícito lo hace, y un ping-restart provocado por un par muerto hace lo mismo. Ambos dejan vivo el proceso y vuelven a ejecutar la configuración de la conexión, y ahí es donde las opciones se ganan su lugar.

Solo la fila del reinicio suave es lo que cambian estas dos opciones, y el trabajo que se saltan es la parte cara en un enlace ocupado. Reabrir un dispositivo derriba las direcciones y rutas asociadas a él, y reconstruirlas puede perder paquetes que estaban en vuelo cuando comenzó el reinicio. Una parada destruye los mismos objetos sin ninguna opción para conservarlos.

Por qué existen las opciones en absoluto

Un servidor OpenVPN endurecido suele arrancar como root, abre sus claves y su dispositivo y luego pasa a un usuario sin privilegios. Tras ese paso, algunas operaciones simplemente desaparecen. Leer un archivo de clave con modo 0600, crear una interfaz de red o cambiar rutas pueden ser rechazados.

Sin las opciones persist, un par que guarde silencio el tiempo suficiente para activar ping-restart forzaría exactamente esas operaciones. La reconexión fallaría aunque nada de la configuración hubiera cambiado. El proceso parecería morir sin motivo, y el registro mostraría un error de permisos en lugar de un error de red.

Con ellas, el reinicio suave reutiliza lo que la fase privilegiada ya obtuvo. No hay magia y el proceso no sobrevive a nada. La adquisición de recursos simplemente se aplaza.

Lea el primer error, no el último

Cuando un reinicio falla, lea el primer error en lugar del último. Una clave protegida, un archivo auth, un ioctl de interfaz y un hook externo son cuatro recursos distintos. Conservar uno no dice nada sobre el acceso a los demás. Un hook que llama a una herramienta de cortafuegos sigue necesitando los privilegios que esa herramienta exige.

Los hooks tienen su propio interruptor. El manual de OpenVPN empareja las opciones persist con up-restart, que decide si los scripts up y down se ejecutan de nuevo tras un reinicio. Una interfaz que se mantuvo arriba, por tanto, no le dice nada sobre si se refrescó su integración de resolución.

# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'

# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0

Ese par de comandos separa los dos modos de fallo en segundos. Una interfaz presente con rutas ausentes es un problema de hook o de ruta. Una interfaz que desapareció significa que el proceso realmente terminó.

Una interfaz conservada no es un kill switch

Si el requisito es que el tráfico nunca salga fuera del túnel, un dispositivo conservado no lo entrega. Las rutas para la otra familia de direcciones, una segunda ruta predeterminada y el caso en que el proceso sale del todo quedan todos fuera del alcance de la opción.

Trate los dos requisitos por separado. Conservar el objeto del túnel entre reconexiones es una comodidad para el demonio. Bloquear la salida cuando el túnel está caído es una política de cortafuegos con sus propias reglas y su propia prueba. Confundirlos produce una configuración que parece defensiva y se comporta como una reconexión de mejor esfuerzo.

Nombre el evento antes de diagnosticarlo. Un reinicio suave, un intento de conexión fallido y una parada del servicio son tres eventos con tres comportamientos, y solo el primero es lo que describen estas opciones.