Systemd versus NetworkManager: wie start de VPN bij het opstarten?

Twee Ubuntu-machines uit dezelfde image, één VPN-profiel, tegenovergestelde resultaten bij het inloggen: op de ene staat de tunnel al voordat de desktop verschijnt, op de andere komt hij nooit op. Het profiel is hier niet de variabele. Wat verschilt, is welke van drie componenten de opdracht kreeg hem te starten, en die drie delen geen enkele schakelaar.

Ze naast elkaar vergelijken is sneller dan gokken. Elk van hen faalt op een herkenbare manier, en dat is precies wat de vergelijking de moeite waard maakt.

Drie starters met drie verschillende triggers

De meegeleverde openvpn-service is de oudste route. Het init-script leest een autostart-lijst uit /etc/default/openvpn. Staat die lijst uitgecommentarieerd of is hij leeg, dan start het script elke configuratie die het in die map vindt in plaats van de enige die u hebt toegevoegd. Eén bestand voor één tunnel kan er stilletjes meerdere omhoog brengen.

De tweede rij is degene die mensen verkeerd configureren. NetworkManager houdt het geïmporteerde profiel vast en zal het starten, maar alleen als secundair van een andere verbinding, wat betekent dat de trigger bij de netwerklink hoort en niet bij de VPN.

Vergelijk de installatiekosten en de reikwijdte

De init-scriptroute kost één regel en dekt elke configuratie op de machine. Dat is goed voor een router en verkeerd voor een laptop die op verschillende netwerken inlogt. De NetworkManager-route kost een UUID-opzoekactie en bindt de tunnel aan één basisverbinding. Hij komt op bij de Wi-Fi van het werk en blijft neer op een hotelnetwerk.

Een handgeschreven unit kost het meest en levert de meeste controle op, inclusief de volgorde ten opzichte van andere services. Reikwijdte is de beslissende factor. Heeft de machine één netwerk en één tunnel, dan is de meegeleverde service eerlijk en voorspelbaar. Moet de tunnel een specifiek Wi-Fi-netwerk volgen, dan is de secundaire de enige van de drie die die voorwaarde zonder extra scripting uitdrukt.

Kies één eigenaar en verwijder de andere

Een profiel dat door twee eigenaars wordt gestart, levert timing op die tussen opstartsessies verandert, wat slechter is dan elk van de mechanismen alleen. Kies de eigenaar en schakel daarna het concurrerende pad bewust uit in plaats van per ongeluk.

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

Wordt de meegeleverde route met pensioen gestuurd, doe dat dan in de juiste volgorde: zet AUTOSTART op none, voer systemctl daemon-reload uit zodat de gegenereerde units de nieuwe lijst oppikken, en schakel daarna de template-instantie uit die u niet meer wilt. Wordt het herladen overgeslagen, dan blijven de oude units actief, wat eruitziet alsof de wijziging geen effect had.

Een stop die blijft hangen is een apart probleem met een begrensd antwoord. TimeoutStopSec beperkt hoe lang systemd wacht voordat SIGKILL wordt gestuurd. Een drop-in is de juiste plek om dat in te stellen, want het bewerken van de meegeleverde unit verliest de wijziging bij de volgende upgrade.

Controleer wat er werkelijk is gestart

Herstart en lees het bewijs in plaats van de configuratie te vertrouwen. De unit die de tunnel bezit, toont een actieve toestand en een starttijdstip dat bij het opstarten past, en de VPN-interface bestaat voordat u inlogt.

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

Nog één controle hoort hier: bevestig dat de ExecStart van de unit naar de binary wijst die u denkt. Een lokaal gecompileerde client of een snap-pakket heeft vaak een expliciet pad of een snap run-wrapper nodig, omdat systemd de zoekvolgorde van uw shell niet erft. Het vergelijken van command -v openvpn met het unit-bestand beslecht dat binnen enkele seconden.

Schrijf de gekozen eigenaar in de notities van de machine, naast de profielnaam. De volgende persoon die een ontbrekende tunnel debugt, begint bij die regel in plaats van de vergelijking te herhalen.