Systemd mot NetworkManager: kven startar VPN-en ved oppstart?

To Ubuntu-maskinar frå same image, éin VPN-profil, motsette resultat ved innlogging: på den eine er tunnelen oppe før skrivebordet viser seg, på den andre kjem han aldri opp. Profilen er ikkje variabelen her. Det som skil, er kva av tre komponentar som fekk beskjed om å starte han, og dei tre deler ikkje éin brytar.

Å samanlikne dei side om side er raskare enn å gjette. Kvar av dei feilar på ein gjenkjenneleg måte, og det er nettopp difor samanlikninga er verd å gjere.

Tre startarar med tre ulike utløysarar

Den pakka openvpn-tenesta er den eldste vegen. Init-skriptet les ei autostart-liste frå /etc/default/openvpn. Er den lista kommentert ut eller står ho tom, startar skriptet kvar konfigurasjon det finn i den mappa, i staden for den eine du la til. Éi fil lagd til for éin tunnel kan stille heise fleire.

Den andre rada er den folk konfigurerer feil. NetworkManager held den importerte profilen og vil starte han, men berre som sekundær til ei anna tilkopling, som tyder at utløysaren høyrer til nettverkslenkja og ikkje til VPN-en.

Samanlikn oppsettkostnaden og omfanget

Init-skriptvegen kostar éi line og dekkjer kvar konfigurasjon på maskinen. Det er rett for ein ruter og gale for ein berbar PC som koplar til ulike nettverk. NetworkManager-vegen kostar eit UUID-oppslag og bind tunnelen til éi grunnkopling. Han kjem opp på SSID-et på jobben og blir nede på eit hotellnett.

Ein handskriven unit kostar mest og kjøper mest kontroll, inkludert rekkjefølgje mot andre tenester. Omfanget er den avgjerande faktoren. Har maskinen eitt nett og éin tunnel, er den pakka tenesta ærleg og føreseieleg. Skal tunnelen følgje eit bestemt Wi-Fi-nett, er sekundæren den einaste av dei tre som uttrykkjer det vilkåret utan ekstra skripting.

Vel éin eigar og fjern dei andre

Ein profil som to eigarar startar gir timing som endrar seg mellom oppstartar, noko som er verre enn kvar av mekanismane åleine. Vel eigaren, og slå deretter av den konkurrerande vegen med vilje i staden for ved eit 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"

Viss det er den pakka vegen som blir pensjonert, gjer det i rett rekkjefølgje: set AUTOSTART til none, køyr systemctl daemon-reload slik at dei genererte unitane tek den nye lista, og deaktiver deretter malinstansen du ikkje vil ha lenger. Blir omlastinga hoppa over, blir dei gamle unitane verande aktive, og det ser ut som endringa ikkje hadde nokon effekt.

Ein stopp som heng er eit eige problem med eit avgrensa svar. TimeoutStopSec avgrensar kor lenge systemd ventar før SIGKILL blir send. Ein drop-in er rett stad å setje det, fordi redigering av den pakka uniten misser endringa ved neste oppgradering.

Stadfest kva som faktisk starta

Start på nytt og les prova i staden for å stole på konfigurasjonsfila. Uniten som eig tunnelen viser ein aktiv tilstand og eit starttidspunkt som passar med oppstarten, og VPN-grensesnittet finst før du loggar 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

Éin kontroll meir høyrer heime her: stadfest at ExecStart til uniten peikar på binæra du trur. Ein lokalt kompilert klient eller ein snap-pakke treng ofte ein eksplisitt sti eller ein snap run-wrapper, fordi systemd ikkje arvar søkjerekkjefølgja til skalet ditt. Å samanlikne command -v openvpn med unit-fila avgjer det på sekund.

Skriv den valde eigaren i notata til maskinen, ved sida av profilnamnet. Den neste som feilsøkjer ein manglande tunnel, startar på den lina i staden for å gjenta samanlikninga.