Systemd protiv NetworkManager: ko pokreće VPN pri podizanju?

Dva Ubuntu računala iz iste slike, jedan VPN profil, suprotni rezultati pri prijavi: na jednome je tunel podignut prije nego se pojavi radna površina, a na drugome se nikada ne podiže. Profil ovdje nije varijabla. Razlika je u tome kojoj je od tri komponente naređeno da ga pokrene, a te tri ne dijele istu sklopku.

Usporedba jednoga uz drugo brža je od nagađanja. Svaki od njih zataji na prepoznatljiv način, i upravo zato usporedba ima smisla.

Tri pokretača s tri različita okidača

Pakirana openvpn usluga najstariji je put. Njezina init skripta čita popis za automatsko pokretanje iz /etc/default/openvpn. Ako je taj popis zakomentiran ili ostavljen prazan, skripta pokreće svaku konfiguraciju koju nađe u tome direktoriju umjesto one jedine koju ste dodali. Jedna datoteka dodana za jedan tunel može tiho podići njih nekoliko.

Drugi redak je onaj koji ljudi pogrešno postavljaju. NetworkManager drži uvezeni profil i pokrenut će ga, ali samo kao sekundarno na drugoj vezi, što znači da okidač pripada mrežnom spoju, a ne VPN-u.

Usporedite trošak postavljanja i opseg

Put preko init skripte stoji jedan redak i pokriva svaku konfiguraciju na stroju. To je dobro za usmjerivač, a pogrešno za prijenosnik koji se spaja na različite mreže. Put preko NetworkManagera stoji pretragu UUID-a i veže tunel uz jednu osnovnu vezu. Diže se na radnoj mreži, a ostaje spušten na hotelskoj.

Ručno napisan unit stoji najviše i daje najviše nadzora, uključujući redoslijed prema drugim uslugama. Opseg je odlučujući čimbenik. Ako stroj ima jednu mrežu i jedan tunel, pakirana usluga je poštena i predvidiva. Ako tunel treba slijediti određenu Wi-Fi mrežu, sekundarno je jedino od tri koje taj uvjet izražava bez dodatnog skriptiranja.

Odaberite jednog vlasnika i uklonite ostale

Profil koji pokreću dva vlasnika daje vrijeme koje se mijenja između podizanja, što je gore od bilo kojeg mehanizma samoga. Odaberite vlasnika, pa zatim namjerno onemogućite konkurentski put, a ne slučajno.

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

Ako se povlači pakirani put, učinite to pravim redoslijedom: postavite AUTOSTART na none, pokrenite systemctl daemon-reload da generirani uniti preuzmu novi popis, pa onemogućite predložak instancu koju više ne želite. Preskakanje ponovnog učitavanja ostavlja stare unite aktivnima, pa izgleda kao da promjena nije imala učinka.

Zaustavljanje koje visi zaseban je problem s ograničenim odgovorom. TimeoutStopSec ograničava koliko systemd čeka prije slanja SIGKILL-a. Drop-in je pravo mjesto za to postaviti jer uređivanje pakiranog unita gubi promjenu pri sljedećem ažuriranju.

Provjerite što je stvarno pokrenuto

Ponovno podignite stroj i čitajte dokaze umjesto da vjerujete konfiguracijskoj datoteci. Unit koji posjeduje tunel pokazat će aktivno stanje i vrijeme pokretanja koje se podudara s podizanjem, a VPN sučelje postojat će prije nego 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

Ovdje pripada još jedna provjera: potvrdite da ExecStart unita pokazuje na binar koju mislite. Lokalno prevedeni klijent ili snap paket često traži izričitu putanju ili omotač snap run, jer systemd ne nasljeđuje redoslijed pretraživanja vaše ljuske. Usporedba command -v openvpn s datotekom unita rješava to u sekundama.

Zapišite odabranog vlasnika u bilješke stroja, uz naziv profila. Sljedeća osoba koja bude tražila tunel koji nedostaje krenut će od tog retka umjesto da ponovi usporedbu.