Systemd vs NetworkManager: kto spúšťa VPN pri štarte?

Dva stroje Ubuntu z rovnakého obrazu, jeden profil VPN, opačné výsledky pri prihlásení: na jednom je tunel zdvihnutý skôr, než sa objaví pracovná plocha, na druhom sa nezdvihne nikdy. Profil tu nie je premenná. Rozdiel je v tom, ktorému z troch komponentov bolo povedané, aby ho spustil, a tieto tri nezdieľajú jeden prepínač.

Porovnať ich vedľa seba je rýchlejšie než hádať. Každý zlyháva rozpoznateľným spôsobom, a práve preto má porovnanie zmysel.

Tri spúšťače s tromi rôznymi podnetmi

Zabalená služba openvpn je najstaršia cesta. Jej init skript číta zoznam automatického spúšťania z /etc/default/openvpn. Ak je tento zoznam zakomentovaný alebo prázdny, skript spustí každú konfiguráciu, ktorú v tom adresári nájde, namiesto tej jedinej, ktorú ste pridali. Jeden súbor pridaný pre jeden tunel môže potichu zdvihnúť viacero.

Druhý riadok je ten, ktorý ľudia nastavujú nesprávne. NetworkManager drží importovaný profil a spustí ho, ale len ako sekundárny pri inom pripojení, čo znamená, že spúšťací podnet patrí sieťovému spojeniu, a nie VPN.

Porovnajte náklady na nastavenie a rozsah

Cesta cez init skript stojí jeden riadok a pokrýva každú konfiguráciu na stroji. To je v poriadku pre router a nesprávne pre notebook, ktorý sa pripája k rôznym sieťam. Cesta cez NetworkManager stojí vyhľadanie UUID a viaže tunel na jedno základné pripojenie. Zdvíha sa v pracovnej sieti a v hotelovej zostáva dole.

Ručne napísaná unit stojí najviac a kupuje najviac kontroly, vrátane poradia voči iným službám. Rozhodujúcim faktorom je rozsah. Ak má stroj jednu sieť a jeden tunel, zabalená služba je poctivá a predvídateľná. Ak má tunel nasledovať konkrétnu sieť Wi-Fi, sekundárna je jediná z troch, ktorá túto podmienku vyjadruje bez ďalšieho skriptovania.

Vyberte jedného vlastníka a ostatných odstráňte

Profil spúšťaný dvoma vlastníkmi vytvára časovanie, ktoré sa medzi štartmi mení, čo je horšie než ktorýkoľvek z mechanizmov samotný. Vyberte vlastníka a potom konkurenčnú cestu zakážte zámerne, nie omylom.

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

Ak sa ruší zabalená cesta, urobte to v správnom poradí: nastavte AUTOSTART na none, spustite systemctl daemon-reload, aby generované unity prevzali nový zoznam, a potom zakážte šablónovú inštanciu, ktorú už nechcete. Vynechanie opätovného načítania nechá staré unity aktívne, takže to vyzerá, akoby zmena nemala žiadny účinok.

Zaseknuté zastavenie je samostatný problém s obmedzenou odpoveďou. TimeoutStopSec obmedzuje, ako dlho systemd čaká pred odoslaním SIGKILL. Drop-in je správne miesto, kde to nastaviť, pretože úprava zabalenej unit stráca zmenu pri ďalšej aktualizácii.

Overte, čo sa skutočne spustilo

Reštartujte a čítajte dôkazy namiesto toho, aby ste verili konfiguračnému súboru. Unit, ktorá tunel vlastní, ukáže aktívny stav a čas spustenia zodpovedajúci štartu a rozhranie VPN bude existovať skôr, než sa prihlásite.

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

Patrí sem ešte jedna kontrola: overte, že ExecStart unit ukazuje na binárku, ktorú si myslíte. Lokálne preložený klient alebo balík snap často potrebuje explicitnú cestu alebo obal snap run, pretože systemd nededia poradie hľadania vášho shellu. Porovnanie command -v openvpn so súborom unit to vyrieši za sekundy.

Zapíšte zvoleného vlastníka do poznámok stroja vedľa názvu profilu. Ďalší človek, ktorý bude ladiť chýbajúci tunel, začne od tohto riadka namiesto opakovania porovnania.