Restart služby při OpenVPN up: hooky porážejí tun0.device

Připojení závislé služby k tun0.device vypadá jako odběr tunelu, ale není. Jednotka zařízení odráží existenci rozhraní, což může zůstat platné přes neúspěšné spojení i následné opětovné připojení. Služba pak jedná ve špatný okamžik, nebo nikdy, podle toho, zda rozhraní mezitím zmizelo. Hook, který popisuje událost, na které vám skutečně záleží, je ten, který volá OpenVPN, ne ten, který odvozuje systemd.

Rozhodněte, kterou podmínku služba potřebuje, než zvolíte spouštěč, protože tři kandidáti nejsou zaměnitelní.

Co jednotka zařízení skutečně sleduje

systemd vytváří jednotku zařízení z pohledu jádra na síťové rozhraní, takže tun0.device se stane aktivní, když se rozhraní objeví, a neaktivní, když je odstraněno. S persist-tun měkký restart ponechává rozhraní na místě, takže jednotka nikdy nebliká a nic na ni navázané se nespustí. I bez trvalosti jednotka neříká nic o trasách, DNS ani o tom, zda vzdálená strana odpovídá.

To z ní dělá špatného zástupce pro 'VPN je připravena'. Posluchač, který potřebuje jen místní adresu, může být spokojen s existencí rozhraní, zatímco služba, která volá aplikaci ve vzdálené síti, potřebuje trasy a dostupnost, což jednotka zařízení nedokáže vyjádřit.

up, route-up a up-restart znamenají různé věci

up běží po otevření zařízení TUN/TAP a konfiguraci rozhraní, což je správný okamžik pro posluchač, který váže přidělenou adresu. route-up běží po instalaci tras, podléhá libovolnému nastavenému zpoždění trasy, a hodí se pro práci, která potřebuje dokončenou fázi tras. Ani jedno nedokazuje, že vzdálená aplikace odpovídá. Volba mezi nimi je otázka, co služba potřebuje, ne který hook zní dokončeněji.

S persist-tun restarty znovu používají zařízení, takže up se znovu nespustí, pokud není nastaven up-restart. Tato volba povoluje skript up pro dokumentovaný životní cyklus restartu a jeho prostředí je omezené ve srovnání s prvním startem. Skript, který předpokládá plné prostředí, funguje při prvním připojení a selže při dalším.

Odešlete akci, aniž byste na ni čekali

Hook, který volá systemctl restart synchronně, se může zablokovat proti jednotce, jejíž řazení čeká na tunel. systemctl --no-block try-restart vpn-dependent.service zařadí úlohu do fronty a vrátí se, což hooku brání zablokovat spojení, na které reagoval. try-restart působí jen na běžící jednotku, zatímco restart spustí i neaktivní; vybírejte záměrně, ne ze zvyku.

Zařazení do fronty není ověření. Hook vrací úspěch, jakmile je úloha přijata, takže kontrola se musí odehrát v žurnálu cílové jednotky nebo v jejím skutečném stavu posluchače.

Zásada restartu žije v jednotce, ne v hooku

Jednotka oneshot s RemainAfterExit=yes zůstává aktivní i po skončení svého příkazu a druhý požadavek na start nic nedělá, protože systemd ji považuje za již spuštěnou. To je vlastnost, kolem které se má navrhovat, ne vada, kterou je třeba obcházet opakovanými voláními startu. Pokud akce musí běžet při každém připojení, jednotka potřebuje tvar, který to umožňuje.

After= řadí jednotky a BindsTo= svazuje životnosti, ale ani jedno neznamená 'restartuj to pokaždé, když se VPN znovu připojí'. Jednotka vázaná na tunel se zastaví, když se tunel zastaví; sama se nerestartuje, když se tunel vrátí, pokud ji něco znovu nespustí.

Otestujte tři opětovná připojení, ne jedno

Studený start, úplný restart klienta a měkké opětovné připojení každý procvičuje jinou cestu. Měkké opětovné připojení je to, které odhalí chybějící up-restart, omezené prostředí nebo jednotku zařízení, která nikdy nebyla neaktivní. Spusťte všechny tři a potvrďte oba směry: služba jedná, když tunel vstane, a nerestartuje se při nesouvisejících změnách spojení, jako je roaming Wi-Fi.

Uchovejte nezávislou cestu obnovy, když závislá služba nese váš vlastní administrativní přístup. Hook, který restartuje věc, přes kterou jste připojeni, je změna, která vás může zamknout venku.