Systemd o NetworkManager: qui inicia la VPN en arrencar?
Tres mecanismes poden aixecar el mateix perfil d’Ubuntu, cadascun amb un desencadenant diferent. Compareu-los, quedeu-vos amb un propietari i retireu el duplicat.
Dues màquines Ubuntu de la mateixa imatge, un perfil de VPN i resultats oposats en iniciar la sessió: en una el túnel ja és aixecat abans que aparegui l’escriptori, i en l’altra no s’aixeca mai. Aquí el perfil no és la variable. El que difereix és a quin dels tres components se li va dir que el iniciés, i aquests tres no comparteixen cap interruptor.
Comparar-los l’un al costat de l’altre és més ràpid que endevinar. Cadascun falla d’una manera recognoscible, i això és el que fa que la comparació valgui la pena.
Tres iniciadors amb tres desencadenants diferents
El servei openvpn empaquetat és el camí més antic. El seu script d’inici llegeix una llista d’inici automàtic de /etc/default/openvpn. Si aquesta llista està comentada o buida, l’script inicia totes les configuracions que troba en aquell directori en lloc de l’única que hàgiu afegit. Un fitxer afegit per a un túnel pot aixecar-ne diversos sense 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 segona fila és la que la gent configura malament. NetworkManager té el perfil importat i l’iniciarà, però només com a secundari d’una altra connexió, cosa que significa que el desencadenant pertany a l’enllaç de xarxa i no a la VPN.
Compareu el cost de configuració i l’abast
La ruta del script d’inici costa una línia i cobreix totes les configuracions de la màquina. Això va bé per a un encaminador i és incorrecte per a un portàtil que es connecta a xarxes diferents. La ruta de NetworkManager costa una consulta d’UUID i lliga el túnel a una connexió base. S’aixeca a la xarxa de la feina i queda avall en una xarxa d’hotel.
Una unit escrit a mà costa més i compra el màxim control, inclòs l’ordre respecte d’altres serveis. L’abast és el factor decisiu. Si la màquina té una xarxa i un túnel, el servei empaquetat és honest i previsible. Si el túnel ha de seguir una xarxa Wi-Fi concreta, el secundari és l’únic dels tres que expressa aquesta condició sense scripts addicionals.
Trieu un propietari i elimineu els altres
Un perfil iniciat per dos propietaris produeix una temporització que canvia entre arrencades, cosa que és pitjor que qualsevol dels mecanismes sol. Trieu el propietari i després desactiveu la ruta competitiva a propòsit, no per accident.
# 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 el que es retira és el camí empaquetat, feu-ho en l’ordre correcte: poseu AUTOSTART a none, executeu systemctl daemon-reload per tal que les units generades recullin la nova llista i després desactiveu la instància de plantilla que ja no voleu. Saltar-se la recàrrega deixa les unitats antigues actives, i sembla que el canvi no hagi tingut cap efecte.
Una aturada que es penja és un problema a part amb una resposta acotada. TimeoutStopSec limita quant temps espera systemd abans d’enviar SIGKILL. Un fitxer drop-in és el lloc correcte per establir-ho, perquè editar la unit empaquetada fa perdre el canvi a la propera actualització.
Verifiqueu què s’ha iniciat realment
Reinicieu i llegiu les proves en lloc de confiar en el fitxer de configuració. La unit que posseeix el túnel mostrarà un estat actiu i una marca de temps d’inici que coincideix amb l’arrencada, i la interfície de VPN existirà abans que inicieu la sessió.
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í hi cap una comprovació més: confirmeu que l’ExecStart de la unit apunta al binari que us penseu. Un client compilat localment o un paquet snap sovint necessita una ruta explícita o un embolcall snap run, perquè systemd no hereta l’ordre de cerca del vostre shell. Comparar command -v openvpn amb el fitxer de la unit ho resol en segons.
Escriviu el propietari triat a les notes de la màquina, al costat del nom del perfil. La propera persona que depuri un túnel que falta començarà per aquella línia en lloc de repetir la comparació.