Systemd vs NetworkManager: kdo spouští VPN při startu?

Dva stroje Ubuntu ze stejného obrazu, jeden profil VPN a opačné výsledky při přihlášení: na jednom je tunel zvednutý dřív, než se objeví plocha, na druhém se nezvedne nikdy. Profil tady proměnnou není. Rozdíl je v tom, které ze tří komponent bylo řečeno, aby ho spustila, a tyto tři nesdílejí jeden přepínač.

Porovnat je vedle sebe je rychlejší než hádat. Každý selhává rozpoznatelným způsobem, a právě proto má srovnání smysl.

Tři spouštěče se třemi různými spouštěcími podněty

Zabalená služba openvpn je nejstarší cesta. Její init skript čte seznam automatického spouštění z /etc/default/openvpn. Pokud je tento seznam zakomentovaný nebo prázdný, skript spustí každou konfiguraci, kterou v tom adresáři najde, místo té jediné, kterou jste přidali. Jeden soubor přidaný pro jeden tunel může tiše zvednout několik.

Druhý řádek je ten, který lidé nastavují špatně. NetworkManager drží importovaný profil a spustí ho, ale jen jako sekundární u jiného připojení, což znamená, že spouštěcí podnět patří síťovému spoji, ne VPN.

Porovnejte náklady na nastavení a rozsah

Cesta přes init skript stojí jeden řádek a pokrývá každou konfiguraci na stroji. To je v pořádku pro router a špatné pro notebook, který se připojuje k různým sítím. Cesta přes NetworkManager stojí vyhledání UUID a váže tunel na jedno základní připojení. Zvedne se v pracovní síti a v hotelové zůstane dole.

Ručně psaná unit stojí nejvíc a kupuje nejvíc kontroly, včetně pořadí vůči jiným službám. Rozhodujícím faktorem je rozsah. Pokud má stroj jednu síť a jeden tunel, je zabalená služba poctivá a předvídatelná. Pokud má tunel následovat konkrétní síť Wi-Fi, je sekundární jediný ze tří, kdo tuto podmínku vyjádří bez dalších skriptů.

Vyberte jednoho vlastníka a ostatní odstraňte

Profil spouštěný dvěma vlastníky vytváří časování, které se mezi starty mění, což je horší než kterýkoli z mechanismů samotný. Vyberte vlastníka a potom konkurenční cestu zakažte záměrně, ne omylem.

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

Pokud se ruší zabalená cesta, udělejte to ve správném pořadí: nastavte AUTOSTART na none, spusťte systemctl daemon-reload, aby generované unity převzaly nový seznam, a potom zakažte šablonovou instanci, kterou už nechcete. Vynechání znovunačtení nechá staré unity aktivní, takže to vypadá, že změna neměla žádný účinek.

Zaseknuté zastavení je samostatný problém s omezenou odpovědí. TimeoutStopSec omezuje, jak dlouho systemd čeká, než pošle SIGKILL. Drop-in je správné místo, kde to nastavit, protože úprava zabalené unity změnu při další aktualizaci ztratí.

Ověřte, co se skutečně spustilo

Restartujte a čtěte důkazy místo toho, abyste věřili konfiguračnímu souboru. Unit, která tunel vlastní, ukáže aktivní stav a čas spuštění odpovídající startu a rozhraní VPN bude existovat dřív, než se přihlásíte.

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

Patří sem ještě jedna kontrola: ověřte, že ExecStart unity ukazuje na binárku, kterou si myslíte. Lokálně zkompilovaný klient nebo balíček snap často potřebuje explicitní cestu nebo obal snap run, protože systemd nedědí pořadí hledání vašeho shellu. Porovnání command -v openvpn se souborem unity to vyřeší během sekund.

Zapište zvoleného vlastníka do poznámek stroje vedle názvu profilu. Další člověk, který bude ladit chybějící tunel, začne od tohoto řádku místo aby srovnání opakoval.