Systemd mot NetworkManager: hvem starter VPN-en ved oppstart?

To Ubuntu-maskiner fra samme image, én VPN-profil, motsatte resultater ved innlogging: på den ene er tunnelen oppe før skrivebordet vises, på den andre kommer den aldri opp. Profilen er ikke variabelen her. Det som er forskjellig, er hvilken av tre komponenter som fikk beskjed om å starte den, og de tre deler ikke én bryter.

Å sammenligne dem side om side er raskere enn å gjette. Hver av dem feiler på en gjenkjennelig måte, og det er nettopp derfor sammenligningen er verdt å gjøre.

Tre startere med tre forskjellige utløsere

Den pakkede openvpn-tjenesten er den eldste veien. Init-skriptet leser en autostart-liste fra /etc/default/openvpn. Hvis den listen er kommentert ut eller står tom, starter skriptet hver konfigurasjon det finner i den mappen, i stedet for den ene du la til. Én fil lagt til for én tunnel kan stille heise flere.

Den andre raden er den folk konfigurerer feil. NetworkManager holder den importerte profilen og vil starte den, men bare som sekundær til en annen tilkobling, som betyr at utløseren tilhører nettverkslenken og ikke VPN-en.

Sammenlign oppsettkostnaden og omfanget

Init-skriptveien koster én linje og dekker hver konfigurasjon på maskinen. Det er riktig for en ruter og galt for en bærbar PC som kobler til ulike nettverk. NetworkManager-veien koster et UUID-oppslag og binder tunnelen til én grunnforbindelse. Den kommer opp på arbeidsplassens SSID og blir nede på et hotellnett.

En håndskrevet unit koster mest og kjøper mest kontroll, inkludert rekkefølge mot andre tjenester. Omfanget er den avgjørende faktoren. Har maskinen ett nett og én tunnel, er den pakkede tjenesten ærlig og forutsigbar. Skal tunnelen følge et bestemt Wi-Fi-nett, er sekundæren den eneste av de tre som uttrykker den betingelsen uten ekstra skripting.

Velg én eier og fjern de andre

En profil som startes av to eiere gir timing som endrer seg mellom oppstarter, noe som er verre enn hver av mekanismene alene. Velg eieren, og slå deretter av den konkurrerende veien med vilje i stedet for ved et uhell.

# 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"

Hvis det er den pakkede veien som pensjoneres, gjør det i riktig rekkefølge: sett AUTOSTART til none, kjør systemctl daemon-reload slik at de genererte unitene tar den nye listen, og deaktiver deretter malinstansen du ikke vil ha lenger. Hoppes omlastingen over, blir de gamle unitene aktive, og det ser ut som endringen ikke hadde noen effekt.

En stopp som henger er et eget problem med et avgrenset svar. TimeoutStopSec begrenser hvor lenge systemd venter før SIGKILL sendes. En drop-in er riktig sted å sette det, fordi redigering av den pakkede uniten mister endringen ved neste oppgradering.

Bekreft hva som faktisk startet

Start på nytt og les bevisene i stedet for å stole på konfigurasjonsfilen. Uniten som eier tunnelen viser en aktiv tilstand og et starttidspunkt som passer med oppstarten, og VPN-grensesnittet finnes før du logger inn.

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

Én kontroll mer hører hjemme her: bekreft at unitens ExecStart peker på binæren du tror. En lokalt kompilert klient eller en snap-pakke trenger ofte en eksplisitt sti eller en snap run-wrapper, fordi systemd ikke arver søkerekkefølgen til skallet ditt. Å sammenligne command -v openvpn med unit-filen avgjør det på sekunder.

Skriv den valgte eieren i maskinens notater, ved siden av profilnavnet. Den neste som feilsøker en manglende tunnel, starter på den linjen i stedet for å gjenta sammenligningen.