¿OpenVPN dice active (exited)? Encuentre la instancia que inició

Usted comprueba el túnel, ejecuta systemctl status openvpn y obtiene active (exited) sin Main PID y con una lista de procesos vacía. La lectura natural es que el servicio arrancó y murió, así que abre la unidad, encuentra /bin/true y concluye que el paquete está roto. En el empaquetado de Debian ese estado es el contenedor trabajando como se diseñó, y el túnel vive en una de las unidades de instancia que inicia. La unidad agregada nunca le dirá qué instancia la construyó.

Qué significa realmente active (exited) en esta unidad

La unidad empaquetada es de una sola vez: su ExecStart es /bin/true, y RemainAfterExit=yes es lo que mantiene una unidad terminada informada como active (exited). Quite esa directiva y la misma tarea /bin/true exitosa termina en inactive (dead), que es exactamente el estado que la gente espera y lee mal en la dirección contraria. El comando es un marcador de posición, y la unidad informa sobre trabajo que realizan otras unidades. Nada de ese arreglo está roto, y sustituir /bin/true cambia el contrato de empaquetado, no el túnel.

El contenedor delega. Inicia las unidades de instancia que proporciona la configuración del paquete o su generador de systemd, y por eso una lista de procesos vacía no demuestra nada sobre el túnel. Cuando no se selecciona ninguna instancia, el contenedor sigue teniendo éxito y sigue sin iniciar nada. El estado responde si el contenedor se ejecutó, no si existe un túnel.

Lea las tres líneas de la salida de status en lugar de la palabra entre paréntesis. Loaded nombra el archivo de unidad que leyó systemd, Active lleva la marca de tiempo de la última ejecución exitosa y la ausencia de Main PID encaja con una tarea de una sola vez ya terminada. Esas tres líneas son también la forma de distinguir este contenedor de un servicio que se cayó un segundo después de arrancar.

Liste las unidades antes de volver a leer el estado

Pregunte a systemd qué existe antes de preguntar qué se ejecuta. Una plantilla puede estar instalada mientras no se crea ninguna instancia, y solo una unidad creada lleva un túnel. Empiece por el conjunto cargado:

systemctl list-units 'openvpn*'

Esa lista es lo que systemd ha cargado en este momento, y es lo más parecido a un inventario de túneles. Los archivos de unidad instalados responden otra pregunta, y esa lista sigue mostrando una plantilla cuando no se ha creado nada:

systemctl list-unit-files 'openvpn*'

Lea las dos listas juntas, porque una plantilla en la segunda y una instancia en la primera son respuestas distintas. Una plantilla que existe y una instancia que se ejecuta no son el mismo hecho, y solo la segunda significa un túnel. Los diseños de paquete también varían entre distribuciones y versiones de OpenVPN. Una plantilla openvpn@ más antigua, un par separado de client y server y un contenedor de distribución pueden ser todos legítimos en su propio empaquetado.

Adáptese a su máquina en lugar del tutorial que encontró. El nombre de instancia en la salida de otra persona puede ser office mientras el suyo es home o work. Lo que se transfiere es el método, no la cadena.

Siga el nombre de instancia hasta el archivo que lee

En la plantilla de client upstream el directorio de trabajo de la unidad es /etc/openvpn/client y su comando toma %i.conf de allí, así que openvpn-client@office lee /etc/openvpn/client/office.conf. Confirme esa correspondencia en la unidad instalada en lugar de confiar en el ejemplo, porque la plantilla que tiene puede ser más antigua o una reescritura de la distribución:

systemctl cat [email protected]

Lea los drop-in que aparecen al final de esa salida, porque un archivo bajo .d/ puede cambiar ExecStart, el directorio de trabajo o la ruta de configuración. Un perfil que descargó como office.ovpn no es el archivo que abre la instancia. Esa brecha es la razón habitual de que un error nombre una ruta que nunca editó.

Las rutas relativas dentro del perfil son la siguiente trampa. Mover el archivo principal mientras las referencias ca, cert y key siguen siendo relativas cambia un error de archivo ausente por otro error de archivo ausente. El segundo apunta a un archivo que usted estaba seguro de que existía, y por eso el directorio del perfil importa más que el nombre del archivo.

Iníciela y después lea el registro de esa instancia

Inicie la instancia que acaba de inspeccionar, porque el registro de la unidad agregada no contendrá los errores del túnel. Después lea el registro de este arranque y busque en ese orden un error de configuración, un error de acceso a archivo y un error de conexión, porque cada uno falla en una etapa distinta del arranque.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Iniciar y habilitar son decisiones separadas: start ejecuta la unidad ahora, enable prepara el próximo arranque y enable --now hace ambas cosas en un paso. daemon-reload relee las definiciones de unidad y no reinicia un proceso en ejecución ni aplica un perfil editado. Tras cambiar el perfil, reinicie la instancia, porque eso es lo que relee el archivo.

No ponga un segundo gestor en el mismo túnel

NetworkManager y los gestores de sesión de OpenVPN 3 tienen su propio estado de conexión, y una instancia de systemd junto a uno de ellos pone dos propietarios en el mismo túnel. El síntoma es un túnel que sube y se sustituye segundos después, o uno que se niega a quedarse detenido. Elija el gestor que su distribución documenta para el escritorio y use systemd deliberadamente en un servidor.

Compruebe si ya hay un propietario antes de iniciar una instancia. Cuando un applet de escritorio muestra la conexión, la instancia que usted inicia compite con él en lugar de completarlo. Desactive el gestor que no usa en lugar de ejecutar ambos y esperar que el orden aguante. Ese conflicto también explica registros en los que se establece un túnel y luego lo desmonta un proceso que usted nunca inició.

Responda la pregunta original con el nombre de la instancia, el archivo que leyó y la línea de registro que falló. Las notas de OpenVPN sobre la integración con systemd describen el diseño de la plantilla y la correspondencia de archivo por la que se resuelve el nombre de instancia.