Systemd proti NetworkManagerju: kdo zažene VPN ob zagonu?

Dva računalnika Ubuntu iz iste slike, en profil VPN, nasprotna rezultata pri prijavi: na enem je tunel dvignjen še preden se pojavi namizje, na drugem se nikoli ne dvigne. Profil tu ni spremenljivka. Razlika je v tem, kateri od treh komponent je bilo ukazano, da ga zažene, in te tri si ne delijo enega stikala.

Primerjava enega ob drugem je hitrejša od ugibanja. Vsak od njih odpove na prepoznaven način, in prav zato je primerjava smiselna.

Trije zaganjalniki s tremi različnimi sprožilci

Pakirana storitev openvpn je najstarejša pot. Njena init skripta bere seznam samodejnega zagona iz /etc/default/openvpn. Če je ta seznam zakomentiran ali prazen, skripta zažene vsako konfiguracijo, ki jo najde v tej mapi, namesto tiste edine, ki ste jo dodali. Ena datoteka, dodana za en tunel, lahko tiho dvigne več.

Druga vrstica je tista, ki jo ljudje nastavijo napačno. NetworkManager drži uvožen profil in ga bo zagnal, a samo kot sekundarno pri drugi povezavi, kar pomeni, da sprožilec pripada omrežni povezavi in ne VPN.

Primerjajte stroške nastavitve in obseg

Pot prek init skripte stane eno vrstico in pokrije vsako konfiguracijo na stroju. To je v redu za usmerjevalnik in narobe za prenosnik, ki se povezuje v različna omrežja. Pot prek NetworkManagerja stane iskanje UUID in veže tunel na eno osnovno povezavo. Dvigne se v pisarniškem omrežju, v hotelskem pa ostane spodaj.

Ročno napisan unit stane največ in prinese največ nadzora, vključno z vrstnim redom glede na druge storitve. Odločilni dejavnik je obseg. Če ima stroj eno omrežje in en tunel, je pakirana storitev poštena in predvidljiva. Če naj tunel sledi določenemu omrežju Wi-Fi, je sekundarno edino od treh, ki ta pogoj izrazi brez dodatnega skriptiranja.

Izberite enega lastnika in odstranite druge

Profil, ki ga zaženeta dva lastnika, ustvari časovni potek, ki se med zagoni spreminja, kar je slabše od katerega koli mehanizma samega. Izberite lastnika in nato konkurenčno pot namerno, ne po nesreči, onemogočite.

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

Če se umika pakirana pot, storite to v pravem vrstnem redu: nastavite AUTOSTART na none, zaženite systemctl daemon-reload, da ustvarjeni uniti prevzamejo nov seznam, nato onemogočite predlogo instance, ki je ne želite več. Če ponovno nalaganje izpustite, stari uniti ostanejo aktivni, zato je videti, kot da sprememba ni imela nobenega učinka.

Zaustavljanje, ki se obesi, je ločen problem z omejenim odgovorom. TimeoutStopSec omejuje, kako dolgo systemd čaka preden pošlje SIGKILL. Datoteka drop-in je pravo mesto za to nastavitev, ker urejanje pakirane enote izgubi spremembo pri naslednji nadgradnji.

Preverite, kaj se je dejansko zagnalo

Znova zaženite in berite dokaze, namesto da bi zaupali konfiguracijski datoteki. Unit, ki ima tunel, bo pokazal aktivno stanje in čas zagona, ki se ujema z zagonom, vmesnik VPN pa bo obstajal, preden se prijavite.

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

Sem sodi še en pregled: preverite, da ExecStart unitu kaže na binarno datoteko, ki jo mislite. Lokalno prevedeni odjemalec ali paket snap pogosto potrebuje izrecno pot ali ovoj snap run, ker systemd ne podeduje vrstnega reda iskanja vaše lupine. Primerjava command -v openvpn z datoteko unitu to razreši v sekundah.

Izbranega lastnika zapišite v zapiske stroja, ob ime profila. Naslednja oseba, ki bo odpravljala manjkajoči tunel, bo začela pri tej vrstici, namesto da bi ponovila primerjavo.