Systemd frente a NetworkManager: ¿quién inicia la VPN al arrancar?
Tres mecanismos pueden levantar el mismo perfil de Ubuntu, cada uno con un disparador distinto. Compárelos, quédese con un dueño y retire el duplicado.
Dos máquinas Ubuntu de la misma imagen, un perfil de VPN, resultados opuestos al iniciar sesión: en una el túnel está arriba antes de que aparezca el escritorio y en la otra nunca llega a subir. El perfil no es la variable aquí. Lo que cambia es a cuál de tres componentes se le dijo que lo iniciara, y esos tres no comparten un interruptor.
Compararlos uno al lado del otro es más rápido que adivinar. Cada uno falla de una forma reconocible, y eso es lo que hace que la comparación valga la pena.
Tres iniciadores con tres disparadores distintos
El servicio openvpn empaquetado es la vía más antigua. Su script de inicio lee una lista de arranque automático de /etc/default/openvpn. Si esa lista está comentada o vacía, el script inicia todas las configuraciones que encuentra en ese directorio en lugar de la única que usted añadió. Un archivo añadido para un túnel puede levantar varios sin avisar.
| Starter | What triggers it | Typical failure |
|---|---|---|
| Init script and templated units | Boot, plus anything in the autostart list | Starts every config, not the one you meant |
| NetworkManager secondary | Activation of the base Wi-Fi or Ethernet profile | Nothing happens until that base link comes up |
| Hand-written unit or wrapper | Whatever its WantedBy and ExecStart say | Runs a different binary or environment than your shell |
La segunda fila es la que la gente configura mal. NetworkManager tiene el perfil importado y lo iniciará, pero solo como secundario de otra conexión, lo que significa que el disparador pertenece al enlace de red y no a la VPN.
Compare el coste de configuración y el alcance
La ruta del script de inicio cuesta una línea y cubre todas las configuraciones del equipo. Eso está bien para un router y mal para un portátil que se conecta a redes distintas. La ruta de NetworkManager cuesta una búsqueda de UUID y ata el túnel a una conexión base. Sube en la Wi-Fi del trabajo y se queda abajo en una red de hotel.
Una unidad escrita a mano cuesta más y compra el máximo control, incluido el orden respecto a otros servicios. El alcance es el factor decisivo. Si el equipo tiene una red y un túnel, el servicio empaquetado es honesto y predecible. Si el túnel debe seguir una red Wi-Fi concreta, el secundario es el único de los tres que expresa esa condición sin scripting adicional.
Elija un dueño y elimine los demás
Un perfil iniciado por dos dueños produce una temporización que cambia entre arranques, lo que es peor que cualquiera de los mecanismos por separado. Elija el dueño y luego desactive la ruta competidora a propósito, no por accidente.
# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'
# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"Si la vía que se retira es la empaquetada, hágalo en el orden correcto: ponga AUTOSTART en none, ejecute systemctl daemon-reload para que las unidades generadas recojan la nueva lista y luego desactive la instancia de plantilla que ya no quiere. Saltarse la recarga deja las unidades antiguas activas, y parece que el cambio no tuvo ningún efecto.
Una parada que se cuelga es un problema aparte con una respuesta acotada. TimeoutStopSec limita cuánto espera systemd antes de enviar SIGKILL. Un archivo drop-in es el lugar correcto para fijarlo, porque editar la unidad empaquetada pierde el cambio en la siguiente actualización.
Verifique qué se inició realmente
Reinicie y lea las pruebas en lugar de confiar en el archivo de configuración. La unidad dueña del túnel mostrará un estado activo y una marca de tiempo de inicio que coincide con el arranque, y la interfaz de VPN existirá antes de que inicie sesión.
systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0Aquí encaja una comprobación más: confirme que el ExecStart de la unidad apunta al binario que usted cree. Un cliente compilado localmente o un paquete snap suele necesitar una ruta explícita o un envoltorio snap run, porque systemd no hereda el orden de búsqueda de su shell. Comparar command -v openvpn con el archivo de la unidad lo resuelve en segundos.
Escriba el dueño elegido en las notas del equipo, junto al nombre del perfil. La próxima persona que depure un túnel ausente empezará por esa línea en lugar de repetir la comparación.