Systemd eller NetworkManager: vem startar VPN:en vid uppstart?

Två Ubuntu-maskiner från samma avbild, en VPN-profil, motsatta resultat vid inloggning: på den ena är tunneln uppe innan skrivbordet syns, på den andra kommer den aldrig upp. Profilen är inte variabeln här. Det som skiljer är vilken av tre komponenter som fick order att starta den, och de tre delar inte en enda brytare.

Att jämföra dem sida vid sida är snabbare än att gissa. Var och en misslyckas på ett igenkännbart sätt, och det är just därför jämförelsen är värd att göra.

Tre startare med tre olika utlösare

Den paketerade openvpn-tjänsten är den äldsta vägen. Dess init-skript läser en autostart-lista från /etc/default/openvpn. Är den listan utkommenterad eller lämnad tom startar skriptet varje konfiguration det hittar i den katalogen i stället för den enda du lade till. En enda fil tillagd för en tunnel kan tyst få flera att komma upp.

Den andra raden är den folk konfigurerar fel. NetworkManager håller den importerade profilen och kommer att starta den, men bara som sekundär till en annan anslutning, vilket betyder att utlösaren hör till nätverkslänken och inte till VPN:en.

Jämför installationskostnaden och omfattningen

Init-skriptvägen kostar en rad och täcker varje konfiguration på maskinen. Det är rätt för en router och fel för en bärbar dator som ansluter till olika nätverk. NetworkManager-vägen kostar en UUID-sökning och binder tunneln till en basanslutning. Den kommer upp på arbetsplatsens SSID och ligger kvar nere på ett hotellnät.

En handskriven unit kostar mest och köper mest kontroll, inklusive ordningen gentemot andra tjänster. Omfattningen är den avgörande faktorn. Har maskinen ett nät och en tunnel är den paketerade tjänsten ärlig och förutsägbar. Ska tunneln följa ett visst Wi-Fi-nät är sekundären den enda av de tre som uttrycker det villkoret utan extra skriptning.

Välj en ägare och ta bort de andra

En profil som startas av två ägare ger en timing som ändras mellan uppstarter, vilket är sämre än var och en av mekanismerna för sig. Välj ägaren och stäng sedan av den konkurrerande vägen med avsikt i stället för av misstag.

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

Om det är den paketerade vägen som pensioneras ska det göras i rätt ordning: sätt AUTOSTART till none, kör systemctl daemon-reload så att de genererade uniterna tar den nya listan och inaktivera sedan mallinstansen du inte längre vill ha. Hoppas omladdningen över ligger de gamla uniterna kvar som aktiva, och det ser ut som om ändringen inte hade någon effekt.

Ett stopp som hänger är ett separat problem med ett avgränsat svar. TimeoutStopSec begränsar hur länge systemd väntar innan SIGKILL skickas. En drop-in är rätt plats att ställa in det på, eftersom redigering av den paketerade uniten tappar ändringen vid nästa uppgradering.

Verifiera vad som faktiskt startade

Starta om och läs bevisen i stället för att lita på konfigurationsfilen. Uniten som äger tunneln visar ett aktivt tillstånd och en starttid som stämmer med uppstarten, och VPN-gränssnittet finns innan du loggar in.

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

En kontroll till hör hemma här: bekräfta att unitens ExecStart pekar på den binärfil du tror. En lokalt kompilerad klient eller ett snap-paket behöver ofta en explicit sökväg eller ett snap run-omslag, eftersom systemd inte ärver skalets sökordning. Att jämföra command -v openvpn med unit-filen avgör det på sekunder.

Skriv den valda ägaren i maskinens anteckningar, bredvid profilnamnet. Nästa person som felsöker en saknad tunnel börjar på den raden i stället för att upprepa jämförelsen.