Reštart služby pri OpenVPN up: hooky porážajú tun0.device

Pripojenie závislej služby k tun0.device vyzerá ako odber tunela, ale nie je. Jednotka zariadenia odráža existenciu rozhrania, čo môže zostať pravdivé cez neúspešné spojenie aj nasledujúce opätovné pripojenie. Služba potom koná v nesprávnom momente, alebo nikdy, podľa toho, či rozhranie medzitým zmizlo. Hook, ktorý opisuje udalosť, na ktorej vám skutočne záleží, je ten, ktorý volá OpenVPN, nie ten, ktorý odvodzuje systemd.

Rozhodnite, ktorú podmienku služba potrebuje, skôr než zvolíte spúšťač, pretože traja kandidáti nie sú zameniteľní.

Čo jednotka zariadenia skutočne sleduje

systemd vytvára jednotku zariadenia z pohľadu jadra na sieťové rozhranie, takže tun0.device sa stane aktívnou, keď sa rozhranie objaví, a neaktívnou, keď je odstránené. S persist-tun mäkký reštart ponecháva rozhranie na mieste, takže jednotka nikdy nebliká a nič na ňu naviazané sa nespustí. Aj bez trvalosti jednotka nehovorí nič o trasách, DNS ani o tom, či vzdialená strana odpovedá.

To z nej robí zlého zástupcu pre 'VPN je pripravená'. Poslucháč, ktorý potrebuje iba miestnu adresu, môže byť spokojný s existenciou rozhrania, zatiaľ čo služba, ktorá volá aplikáciu vo vzdialenej sieti, potrebuje trasy a dostupnosť, čo jednotka zariadenia nedokáže vyjadriť.

up, route-up a up-restart znamenajú rôzne veci

up beží po otvorení zariadenia TUN/TAP a konfigurácii rozhrania, čo je správny okamih pre poslucháča, ktorý viaže pridelenú adresu. route-up beží po nainštalovaní trás, podlieha akémukoľvek nastavenému oneskoreniu trasy, a hodí sa pre prácu, ktorá potrebuje dokončenú fázu trás. Ani jedno nedokazuje, že vzdialená aplikácia odpovedá. Voľba medzi nimi je otázka, čo služba potrebuje, nie ktorý hook znie dokončenejšie.

S persist-tun reštarty znova používajú zariadenie, takže up sa znova nespustí, ak nie je nastavený up-restart. Táto voľba povoľuje skript up pre dokumentovaný životný cyklus reštartu a jeho prostredie je obmedzené v porovnaní s prvým štartom. Skript, ktorý predpokladá plné prostredie, funguje pri prvom pripojení a zlyhá pri ďalšom.

Odošlite akciu bez čakania na ňu

Hook, ktorý volá systemctl restart synchrónne, sa môže zablokovať voči jednotke, ktorej poradie čaká na tunel. systemctl --no-block try-restart vpn-dependent.service zaradí úlohu do frontu a vráti sa, čo hooku bráni zablokovať spojenie, na ktoré reagoval. try-restart pôsobí len na bežiacu jednotku, zatiaľ čo restart spustí aj neaktívnu; vyberajte zámerne, nie zo zvyku.

Zaradenie do frontu nie je overenie. Hook vráti úspech hneď, ako je úloha prijatá, takže kontrola sa musí odohrať v žurnáli cieľovej jednotky alebo v jej skutočnom stave poslucháča.

Zásada reštartu žije v jednotke, nie v hooku

Jednotka oneshot s RemainAfterExit=yes zostáva aktívna aj po skončení svojho príkazu a druhá žiadosť o štart nič nerobí, pretože systemd ju považuje za už spustenú. To je vlastnosť, okolo ktorej sa navrhuje, nie chyba, ktorá sa obchádza opakovanými volaniami štartu. Ak sa akcia musí spúšťať pri každom pripojení, jednotka potrebuje tvar, ktorý to umožňuje.

After= zoraďuje jednotky a BindsTo= spája životnosti, ale ani jedno neznamená 'reštartuj to pri každom opätovnom pripojení VPN'. Jednotka naviazaná na tunel sa zastaví, keď sa tunel zastaví; sama sa nereštartuje, keď sa tunel vráti, ak ju niečo znova nespustí.

Otestujte tri opätovné pripojenia, nie jedno

Studený štart, úplný reštart klienta a mäkké opätovné pripojenie precvičujú každý inú cestu. Mäkké opätovné pripojenie je to, ktoré odhalí chýbajúci up-restart, obmedzené prostredie alebo jednotku zariadenia, ktorá sa nikdy nestala neaktívnou. Spustite všetky tri a potvrďte oba smery: služba koná, keď tunel vstane, a nereštartuje sa pri nesúvisiacich zmenách spojenia, ako je roaming Wi-Fi.

Uchovajte nezávislú cestu obnovy, keď závislá služba nesie váš vlastný administratívny prístup. Hook, ktorý reštartuje vec, cez ktorú ste pripojení, je zmena, ktorá vás môže zamknúť vonku.