Un solo drop-in de OpenVPN cambió todos los túneles: instancia frente a plantilla

Una política de reinicio añadida para un túnel empieza a aplicarse a todos los túneles de la máquina. No es un fallo de systemd; es la diferencia entre un drop-in de instancia y un drop-in de plantilla. La ruta bajo la que escribes el archivo decide cuántos servicios lo heredan.

Elige el alcance antes de la configuración. Los dos directorios parecen casi idénticos, y solo uno de ellos está limitado a la instancia que querías.

El síntoma: una edición, todos los túneles

Un drop-in específico de instancia vive bajo un directorio nombrado con la instancia completa, como [email protected]. Un drop-in de plantilla vive bajo [email protected], con el signo @ y ningún nombre de instancia en medio. El primero se aplica solo a office. El segundo se aplica a cada servicio instanciado a partir de esa plantilla.

La forma de plantilla no alcanza una plantilla [email protected] separada ni alcanza servicios no relacionados con openvpn en el nombre.

Elige el directorio que coincide con el alcance

Ambos directorios están bajo /etc/systemd/system/. Si omites el último componente system, creas una ruta que systemd no lee como una anulación del sistema, y esa es una forma silenciosa de hacer que un archivo con aspecto correcto no haga nada. Escribe la ruta completa una vez y reutilízala.

Un drop-in también necesita el encabezado de sección correcto. La configuración del servicio va bajo [Service]. Un archivo con ajustes pero sin sección se ignora o se rechaza, y la unidad sigue comportándose como antes mientras el archivo está ahí con aspecto de autoridad.

Mantén el propósito en el nombre del archivo si añades más de un drop-in. El orden lexicográfico decide la fusión, y un nombre que dice qué hace el archivo hace legible ese orden.

Lee la unidad fusionada antes de escribir

Lee la unidad fusionada antes de escribir nada. systemctl cat [email protected] imprime la unidad principal y cada drop-in que se aplica, en orden de fusión. Compárala con una segunda instancia cuando estés considerando un cambio de plantilla. Esa comparación muestra exactamente qué servicios heredarían la edición.

Un archivo de instancia no borra la configuración de la plantilla. Ambos se fusionan, así que un valor de plantilla que olvidaste puede seguir vigente.

También participan otros drop-ins con nombre, ajustes de tiempo de ejecución y configuración proporcionada por paquetes. No supongas que el archivo que editaste por última vez es toda la unidad. La salida fusionada es la unidad.

Mantén la política de la unidad fuera del perfil

Mantén separadas la política de la unidad y la configuración de VPN. Una directiva de perfil no se convierte en sintaxis válida de systemd por estar bajo [Service]. Un ajuste de reinicio tampoco pertenece a un archivo .ovpn.

Esa separación es también la razón por la que una política de reinicio no es lo mismo que la recuperación de pares que OpenVPN hace por su cuenta. Decide qué comportamiento quieres antes de elegir un alcance.

Aplícalo y verifica la instancia

Después del cambio, recarga las definiciones del gestor con systemctl daemon-reload. Esa recarga no reinicia el túnel; solo vuelve a leer los archivos de unidad. Luego aplica la acción de ciclo de vida que pretendías a la instancia exacta.

Verifica leyendo de nuevo la unidad cargada y observando el comportamiento que cambiaste. Un reinicio que lleva trabajo activo merece una interrupción planificada, no una prueba rápida en un túnel de producción. Anota el propósito y el alcance de la anulación junto al despliegue para que la siguiente persona sepa si el archivo debía compartirse.

Si la política es realmente compartida, muévela deliberadamente a la plantilla y comprueba una segunda instancia antes de darlo por hecho. La referencia de unidades de systemd documenta la precedencia de los drop-ins y el orden de fusión.