Systemd o NetworkManager: chi avvia la VPN al boot?
Tre meccanismi possono alzare lo stesso profilo Ubuntu, ciascuno con un trigger diverso. Confrontali, tieni un solo proprietario e ritira il duplicato.
Due macchine Ubuntu dalla stessa immagine, un solo profilo VPN, risultati opposti al login: su una il tunnel è già su prima che compaia il desktop, sull’altra non sale mai. Il profilo non è la variabile qui. Ciò che cambia è quale di tre componenti ha ricevuto l’ordine di avviarlo, e quei tre non condividono un interruttore.
Confrontarli fianco a fianco è più rapido che indovinare. Ognuno fallisce in modo riconoscibile, ed è questo che rende il confronto utile.
Tre avviatori con tre trigger diversi
Il servizio openvpn pacchettizzato è la via più antica. Il suo script di init legge un elenco di avvio automatico da /etc/default/openvpn. Se quell’elenco è commentato o lasciato vuoto, lo script avvia ogni configurazione che trova in quella directory invece dell’unica che hai aggiunto. Un solo file aggiunto per un tunnel può alzarne diversi senza farsi notare.
| 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 seconda riga è quella che le persone configurano male. NetworkManager detiene il profilo importato e lo avvierà, ma solo come secondario di un’altra connessione, il che significa che il trigger appartiene al collegamento di rete e non alla VPN.
Confronta il costo di configurazione e la portata
La via dello script di init costa una riga e copre ogni configurazione della macchina. Va bene per un router ed è sbagliata per un portatile che si collega a reti diverse. La via NetworkManager costa una ricerca di UUID e lega il tunnel a una connessione di base. Sale sulla Wi-Fi dell’ufficio e resta giù su una rete d’albergo.
Una unit scritta a mano costa di più e compra il massimo controllo, compreso l’ordinamento rispetto agli altri servizi. La portata è il fattore decisivo. Se la macchina ha una rete e un tunnel, il servizio pacchettizzato è onesto e prevedibile. Se il tunnel deve seguire una rete Wi-Fi precisa, il secondario è l’unico dei tre a esprimere quella condizione senza scripting aggiuntivo.
Scegli un proprietario e rimuovi gli altri
Un profilo avviato da due proprietari produce una temporizzazione che cambia tra un boot e l’altro, il che è peggio di ciascuno dei meccanismi da solo. Scegli il proprietario, poi disattiva la via concorrente di proposito, non per caso.
# 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 la via che viene ritirata è quella pacchettizzata, fallo nell’ordine giusto: imposta AUTOSTART su none, esegui systemctl daemon-reload così le unit generate recepiscono il nuovo elenco, poi disattiva l’istanza modello che non vuoi più. Saltare il ricaricamento lascia attive le vecchie unit, e sembra che la modifica non abbia avuto alcun effetto.
Un arresto che si blocca è un problema separato con una risposta circoscritta. TimeoutStopSec limita quanto systemd attende prima di inviare SIGKILL. Un file drop-in è il posto giusto per impostarlo, perché modificare la unit pacchettizzata perde la modifica al successivo aggiornamento.
Verifica che cosa è stato avviato davvero
Riavvia e leggi le prove invece di fidarti del file di configurazione. La unit proprietaria del tunnel mostrerà uno stato attivo e un timestamp di avvio coerente con il boot, e l’interfaccia VPN esisterà prima che tu acceda.
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 tun0Qui rientra un controllo in più: verifica che l’ExecStart della unit punti al binario che pensi. Un client compilato localmente o un pacchetto snap richiede spesso un percorso esplicito o un wrapper snap run, perché systemd non eredita l’ordine di ricerca della tua shell. Confrontare command -v openvpn con il file della unit lo risolve in pochi secondi.
Scrivi il proprietario scelto nelle note della macchina, accanto al nome del profilo. La prossima persona che eseguirà il debug di un tunnel mancante partirà da quella riga invece di ripetere il confronto.