Una instancia de OpenVPN aparece al arrancar con un nombre que no reconoces, y detenerla funciona hasta el siguiente reinicio. Ese patrón significa que has eliminado el proceso pero no la activación. Son dos objetos distintos, y solo uno de ellos es visible en una pantalla de estado. Encontrar la activación requiere cuatro comandos de solo lectura y una decisión.

Nombra primero la unidad exacta

Parte del nombre de la unidad en el journal, no del nombre de un archivo de perfil. La instancia puede llamarse openvpn@, openvpn-client@, openvpn-server@ o algo específico de la distribución, y adivinar el nombre te lleva a la plantilla equivocada. La salida de estado nombra la unidad que realmente se ejecutó, y ese es el único nombre que importa aquí. Cópialo exactamente, incluido cualquier sufijo.

Los siguientes comandos describen esa unidad sin cambiar nada. systemctl show informa la ruta del fragmento, la ruta de origen, el estado del archivo de unidad, los posibles drop-ins y qué la activó. list-dependencies --reverse muestra qué unidades cargadas apuntan a ella. Ambos son de solo lectura, así que ejecútalos antes de formar una teoría.

Sustituye el nombre observado en todas partes. Un nombre de ejemplo copiado es la forma más común de investigar el servicio equivocado, y produce respuestas seguras sobre una unidad que nunca se ejecutó.

Lee la plantilla para conocer el nombre del archivo

Una unidad de instancia es una expansión de una plantilla, y la plantilla decide qué archivo de configuración lee. Una línea de comandos que termina en un marcador de posición por instancia se resuelve en el nombre de la instancia más el sufijo. Si el sufijo es .conf y la instancia se llama old, el archivo es old.conf. Si llamas a la instancia old.conf, la misma plantilla pide old.conf.conf.

Ese detalle explica una clase de duplicados. Alguien añade una segunda instancia con el nombre equivocado, la primera sigue ejecutándose y el host acaba con dos túneles y un registro confuso.

Lee la plantilla efectiva en lugar del archivo que recuerdas haber editado. Un drop-in puede sustituir la línea de comandos, y la sustitución es lo que se ejecuta al arrancar.

Rastrea cómo entra en la transacción de arranque

Tres rutas son habituales: un enlace wants desde un target, un requisito de otra unidad o una unidad generada por un generador de paquetes. El listado de dependencias inversas cubre las dos primeras como entradas cargadas del grafo. No cubre un temporizador, un hook ni una petición externa, y por eso el listado es una prueba y no una auditoría completa.

La salida generada en /run/systemd/generator es un producto, no una fuente. Editarla solo sobrevive hasta la siguiente generación, y por eso una corrección aplicada allí parece exitosa y luego revierte.

Comprueba la entrada documentada del paquete antes de suponer de dónde lee el generador. Un escaneo no documentado de un directorio es la razón habitual por la que aparece una unidad sin un enlace de activación.

Elimina la activación, no solo el proceso

Si la instancia está activada directamente y es realmente obsoleta, systemctl disable --now la detiene y elimina el enlace de arranque en un solo paso. Comprueba primero que este túnel no sea tu única vía administrativa hacia el host. El comando es un ejemplo de ciclo de vida, no una sugerencia de detener cada VPN de la máquina. Ejecuta la comprobación antes del comando, no después.

Las dos mitades son separables y a menudo se confunden. Desactivar no detiene un servicio en ejecución, y detener no elimina la activación, así que un comando parcial explica un problema que vuelve al arrancar.

Una unidad desactivada aún puede ser iniciada por otra unidad o por una petición explícita. Cuando un generador posee la activación, corrige la entrada del generador en lugar de desactivar su salida. El enmascaramiento bloquea más rutas pero puede romper dependencias, así que no sustituye a la comprensión.

Verifica con un reinicio, no con una pantalla de estado

Recarga systemd si han cambiado las definiciones de unidad o las entradas del generador, y después inspecciona el estado resultante. Una recarga del daemon no empuja un perfil nuevo dentro de un túnel en ejecución, así que las dos comprobaciones son independientes. Programa un reinicio y confirma que la instancia sigue ausente mientras el túnel previsto sigue funcionando.

Conserva el perfil antiguo hasta que se entienda su propiedad, y retíralo después mediante el proceso previsto. El éxito es una unidad ausente y una vía de acceso funcional, no una unidad fallida que falta en una pantalla.

Artículos relacionados