Systemd fronte a NetworkManager: quen inicia a VPN ao arrincar?

Dous equipos Ubuntu da mesma imaxe, un perfil de VPN, resultados opostos ao iniciar sesión: nun o túnel está arriba antes de que apareza o escritorio e no outro nunca chega a subir. O perfil non é a variable aquí. O que cambia é a cal de tres compoñentes se lle dixo que o iniciase, e eses tres non comparten un interruptor.

Comparalos un ao lado do outro é máis rápido que adiviñar. Cada un falla dunha forma recoñecible, e iso é o que fai que a comparación pague a pena.

Tres iniciadores con tres disparadores distintos

O servizo openvpn empaquetado é a vía máis antiga. O seu script de inicio le unha lista de arrinque automático de /etc/default/openvpn. Se esa lista está comentada ou baleira, o script inicia todas as configuracións que atopa nese directorio en lugar da única que vostede engadiu. Un ficheiro engadido para un túnel pode levantar varios sen avisar.

A segunda fila é a que a xente configura mal. NetworkManager ten o perfil importado e iniciarao, pero só como secundario doutra conexión, o que significa que o disparador pertence á ligazón de rede e non á VPN.

Compare o custo de configuración e o alcance

A ruta do script de inicio custa unha liña e cobre todas as configuracións do equipo. Iso está ben para un router e mal para un portátil que se conecta a redes distintas. A ruta de NetworkManager custa unha busca de UUID e ata o túnel a unha conexión base. Sobe na Wi-Fi do traballo e queda abaixo nunha rede de hotel.

Unha unidade escrita a man custa máis e compra o máximo control, incluída a orde respecto doutros servizos. O alcance é o factor decisivo. Se o equipo ten unha rede e un túnel, o servizo empaquetado é honesto e previsible. Se o túnel debe seguir unha rede Wi-Fi concreta, o secundario é o único dos tres que expresa esa condición sen scripting adicional.

Escolla un dono e elimine os demais

Un perfil iniciado por dous donos produce unha temporización que cambia entre arrinques, o que é peor que calquera dos mecanismos por separado. Escolla o dono e logo desactive a ruta competidora a propósito, non 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"

Se a vía que se retira é a empaquetada, fágao na orde correcta: pon AUTOSTART en none, executa systemctl daemon-reload para que as unidades xeradas recollan a nova lista e logo desactiva a instancia de modelo que xa non quere. Saltarse a recarga deixa as unidades antigas activas, e parece que o cambio non tivo ningún efecto.

Unha parada que se colga é un problema aparte cunha resposta acoutada. TimeoutStopSec limita canto espera systemd antes de enviar SIGKILL. Un ficheiro drop-in é o lugar correcto para fixalo, porque editar a unidade empaquetada perde o cambio na seguinte actualización.

Verifique que se iniciou realmente

Reinicie e lea as probas en lugar de confiar no ficheiro de configuración. A unidade dona do túnel mostrará un estado activo e unha marca de tempo de inicio que coincide co arrinque, e a interface 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 tun0

Aquí encaixa unha comprobación máis: confirme que o ExecStart da unidade apunta ao binario que vostede cre. Un cliente compilado localmente ou un paquete snap adoita necesitar unha ruta explícita ou un envoltorio snap run, porque systemd non herda a orde de busca da súa shell. Comparar command -v openvpn co ficheiro da unidade resólveo en segundos.

Escriba o dono elixido nas notas do equipo, xunto ao nome do perfil. A próxima persoa que depure un túnel ausente comezará por esa liña en lugar de repetir a comparación.