Systemd mod NetworkManager: hvem starter VPN ved opstart?

To Ubuntu-maskiner fra det samme image, én VPN-profil, modsatte resultater ved login: på den ene er tunnelen oppe, før skrivebordet vises, og på den anden kommer den aldrig op. Profilen er ikke variablen her. Det, der er forskelligt, er hvilken af tre komponenter der fik besked om at starte den, og de tre deler ikke en kontakt.

At sammenligne dem side om side er hurtigere end at gætte. Hver af dem fejler på en genkendelig måde, og det er præcis derfor, sammenligningen er værd at lave.

Tre startere med tre forskellige udløsere

Den pakkede openvpn-tjeneste er den ældste vej. Dens init-script læser en autostart-liste fra /etc/default/openvpn. Hvis listen er kommenteret ud eller efterladt tom, starter scriptet hver konfiguration, det finder i den mappe, i stedet for den ene, du tilføjede. Én fil tilføjet for én tunnel kan lydløst bringe flere op.

Den anden række er den, folk konfigurerer forkert. NetworkManager holder den importerede profil og starter den, men kun som sekundær til en anden forbindelse, hvilket betyder, at udløseren hører til netværkslinket og ikke til VPN’en.

Sammenlign opsætningsomkostningen og omfanget

Init-script-vejen koster én linje og dækker hver konfiguration på maskinen. Det er fint til en router og forkert til en laptop, der skifter mellem netværk. NetworkManager-vejen koster et UUID-opslag og binder tunnelen til én basisforbindelse. Den kommer op på arbejdets SSID og bliver nede på et hotelnetværk.

En håndskrevet unit koster mest og køber mest kontrol, herunder rækkefølge i forhold til andre tjenester. Omfanget er den afgørende faktor. Hvis maskinen har ét netværk og én tunnel, er den pakkede tjeneste ærlig og forudsigelig. Hvis tunnelen skal følge et bestemt Wi-Fi-netværk, er sekundæren den eneste af de tre, der udtrykker den betingelse uden ekstra scripting.

Vælg én ejer, og fjern de andre

En profil, der startes af to ejere, giver timing, der ændrer sig mellem opstarter, hvilket er værre end hver af mekanismerne alene. Vælg ejeren, og deaktiver derefter den konkurrerende vej med vilje i stedet for ved et uheld.

# 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 vej, der skal pensioneres, gør det i den rigtige rækkefølge: sæt AUTOSTART til none, kør systemctl daemon-reload, så de genererede units fanger den nye liste, og deaktiver derefter den skabeloninstans, du ikke længere vil have. Springes genindlæsningen over, forbliver de gamle units aktive, hvilket ser ud som om ændringen ingen effekt havde.

Et stop, der hænger, er et separat problem med et afgrænset svar. TimeoutStopSec begrænser, hvor længe systemd venter, før SIGKILL sendes. Et drop-in er det rigtige sted at sætte det, fordi redigering af den pakkede unit mister ændringen ved næste opgradering.

Bekræft, hvad der faktisk startede

Genstart og læs beviserne i stedet for at stole på konfigurationsfilen. Den unit, der ejer tunnelen, viser en aktiv tilstand og et starttidspunkt, der matcher opstarten, og VPN-interfacet findes, før du logger ind.

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 kontrol mere hører til her: bekræft, at unitens ExecStart peger på den binære fil, du tror. En lokalt kompileret klient eller en snap-pakke kræver ofte en eksplicit sti eller en snap run-wrapper, fordi systemd ikke arver din shells søgerækkefølge. At sammenligne command -v openvpn med unit-filen afgør det på sekunder.

Skriv den valgte ejer i maskinens noter, ved siden af profilnavnet. Den næste, der fejlfinder en manglende tunnel, starter fra den linje i stedet for at gentage sammenligningen.