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

Dvije Ubuntu mašine s iste slike, jedan VPN profil, suprotni rezultati pri prijavi: na jednoj je tunel podignut prije nego se pojavi radna površina, a na drugoj se nikada ne podiže. Profil ovdje nije promjenljiva. Razlika je u tome kojem je od tri komponente rečeno da ga pokrene, a te tri ne dijele isti prekidač.

Upoređivanje jedne uz drugu brže je od nagađanja. Svaka od njih pada na prepoznatljiv način, i upravo to čini poređenje vrijednim truda.

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

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

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

Uporedite cijenu postavljanja i obim

Put preko init skripte košta jedan red i pokriva svaku konfiguraciju na mašini. To je dobro za ruter, a pogrešno za laptop koji se spaja na različite mreže. Put preko NetworkManagera košta traženje UUID-a i veže tunel za jednu osnovnu vezu. Podiže se na radnoj mreži, a ostaje spušten na hotelskoj.

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

Izaberite jednog vlasnika i uklonite ostale

Profil koji pokreću dva vlasnika daje tajming koji se mijenja između podizanja, što je gore od bilo kojeg mehanizma samog. Izaberite 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 paketni put, učinite to pravim redom: postavite AUTOSTART na none, pokrenite systemctl daemon-reload da generisani uniti preuzmu novu listu, 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 odvojen je problem s ograničenim odgovorom. TimeoutStopSec ograničava koliko systemd čeka prije slanja SIGKILL-a. Drop-in je pravo mjesto da se to postavi, jer uređivanje paketnog unita gubi promjenu pri sljedećem ažuriranju.

Provjerite šta je stvarno pokrenuto

Ponovo podignite mašinu i čitajte dokaze umjesto da vjerujete konfiguracijskoj datoteci. Unit koji posjeduje tunel pokazat će aktivno stanje i vrijeme pokretanja koje se poklapa s podizanjem, a VPN interfejs će postojati 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 binarnu datoteku koju mislite. Lokalno kompajlirani klijent ili snap paket često traži eksplicitnu putanju ili omotač snap run, jer systemd ne nasljeđuje redoslijed pretrage vaše ljuske. Poređenje command -v openvpn s datotekom unita to rješava u sekundama.

Zapišite izabranog vlasnika u bilješke mašine, uz naziv profila. Sljedeća osoba koja bude tražila tunel koji nedostaje krenut će od tog reda umjesto da ponovi poređenje.