Systemd ili NetworkManager: ko podiže VPN pri dizanju sistema?

Dva Ubuntu računara iz iste slike, jedan VPN profil, suprotni ishodi pri prijavi: na jednom je tunel već gore pre nego što se pojavi radna površina, a na drugom se nikad ne diže. Profil ovde nije promenljiva. Razlika je u tome kojoj je od tri komponente naloženo da ga pokrene, a te tri ne dele isti prekidač.

Upoređivanje jedno uz drugo brže je od nagađanja. Svaki od njih pada na prepoznatljiv način, i upravo to čini poređenje vrednim.

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

Paketna openvpn usluga je najstariji put. Njena init skripta čita listu za automatsko pokretanje iz /etc/default/openvpn. Ako je ta lista zakomentarisana ili ostavljena prazna, skripta pokreće svaku konfiguraciju koju nađe u tom direktorijumu, a ne onu jedinu koju ste dodali. Jedan fajl dodat za jedan tunel može tiho podići njih nekoliko.

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

Uporedite cenu postavljanja i obim

Put preko init skripte košta jedan red i pokriva svaku konfiguraciju na mašini. To je u redu za ruter, a pogrešno za laptop koji se spaja na različite mreže. Put preko NetworkManagera košta pretragu UUID-a i vezuje tunel za jednu osnovnu vezu. Diže se na mreži na poslu, a ostaje spušten na hotelskoj.

Ručno napisan unit košta najviše i daje najviše kontrole, uključujući redosled prema drugim uslugama. Obim je odlučujući činilac. Ako mašina ima jednu mrežu i jedan tunel, paketna usluga je poštena i predvidiva. Ako tunel treba da prati određenu Wi-Fi mrežu, sekundarno je jedino od tri koje taj uslov izražava bez dodatnog skriptovanja.

Izaberite jednog vlasnika i uklonite ostale

Profil koji pokreću dva vlasnika daje tajming koji se menja između dizanja sistema, što je gore od bilo kog mehanizma samog. Izaberite vlasnika, pa potom namerno, a ne slučajno, onemogućite konkurentski put.

# 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 paketni put, uradite to pravim redosledom: postavite AUTOSTART na none, pokrenite systemctl daemon-reload da generisani uniti preuzmu novu listu, pa onemogućite instancu šablona koju više ne želite. Preskakanje ponovnog učitavanja ostavlja stare unite aktivnim, pa izgleda kao da promena nije imala nikakav efekat.

Zaustavljanje koje visi jeste zaseban problem sa ograničenim odgovorom. TimeoutStopSec ograničava koliko systemd čeka pre slanja SIGKILL-a. Drop-in je pravo mesto da se to postavi, jer uređivanje paketnog unita gubi promenu pri sledećem ažuriranju.

Proverite šta je zaista pokrenuto

Ponovo dignite sistem i čitajte dokaze umesto da verujete konfiguracionoj datoteci. Unit koji poseduje tunel pokazaće aktivno stanje i vreme pokretanja koje se poklapa sa dizanjem sistema, a VPN interfejs će postojati pre nego što 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

Ovde spada još jedna provera: potvrdite da ExecStart unita pokazuje na binar koji mislite. Lokalno kompajlirani klijent ili snap paket često traži izričitu putanju ili omotač snap run, jer systemd ne nasleđuje redosled pretrage vaše ljuske. Poređenje command -v openvpn sa datotekom unita rešava to u sekundama.

Zapišite izabranog vlasnika u beleške mašine, uz naziv profila. Sledeća osoba koja bude tražila tunel koji nedostaje počeće od tog reda umesto da ponovi poređenje.