Starta om en tjänst vid OpenVPN up: hooks slår tun0.device

Att koppla en beroende tjänst till tun0.device ser ut som en prenumeration på tunneln, och det är det inte. En enhetsenhet speglar att gränssnittet finns, vilket kan förbli sant genom en misslyckad anslutning och återanslutningen som följer. Tjänsten agerar då vid fel tillfälle, eller aldrig, beroende på om gränssnittet försvann däremellan. Hooken som beskriver händelsen du faktiskt bryr dig om är den som OpenVPN anropar, inte den som systemd härleder.

Bestäm vilket villkor tjänsten behöver innan du väljer utlösaren, eftersom de tre kandidaterna inte är utbytbara.

Vad enhetsenheten faktiskt följer

systemd skapar en enhetsenhet utifrån kärnans syn på ett nätverksgränssnitt, så tun0.device blir aktiv när gränssnittet dyker upp och inaktiv när det tas bort. Med persist-tun håller en mjuk omstart gränssnittet på plats, så enheten flappar aldrig och ingenting bundet till den utlöses. Även utan persistens säger enheten ingenting om rutter, DNS eller om den fjärra änden svarar.

Det gör den till en dålig ersättare för 'VPN:et är klart'. En lyssnare som bara behöver den lokala adressen kan nöja sig med att gränssnittet finns, medan en tjänst som anropar en applikation på det fjärra nätverket behöver rutter och nåbarhet, vilket enhetsenheten inte kan uttrycka.

up, route-up och up-restart betyder olika saker

up körs efter att TUN/TAP-enheten öppnats och gränssnittet konfigurerats, vilket är rätt tillfälle för en lyssnare som binder den tilldelade adressen. route-up körs efter att rutter installerats, föremål för eventuell konfigurerad rutterfördröjning, och passar arbete som behöver rutterfasen klar. Ingen av dem bevisar att fjärrapplikationen svarar. Att välja mellan dem är en fråga om vad tjänsten behöver, inte om vilken hook som låter mer färdig.

Med persist-tun återanvänder omstarter enheten, så up körs inte igen om inte up-restart är satt. Det alternativet aktiverar up-skriptet för den dokumenterade omstarts-livscykeln, och dess miljö är reducerad jämfört med en första start. Ett skript som antar den fulla miljön fungerar vid den första anslutningen och misslyckas vid nästa.

Skicka åtgärden utan att vänta på den

En hook som anropar systemctl restart synkront kan gå i baklås mot en enhet vars ordning väntar på tunneln. systemctl --no-block try-restart vpn-dependent.service lägger jobbet i kö och återvänder, vilket hindrar hooken från att blockera anslutningen den reagerade på. try-restart verkar bara på en körande enhet, medan restart också startar en inaktiv; välj medvetet, inte av vana.

Köning är inte verifiering. Hooken returnerar framgång så snart jobbet accepterats, så kontrollen måste ske i målenhetens journal eller i dess faktiska lyssnarläge.

Omstartspolicy bor i enheten, inte i hooken

En oneshot-enhet med RemainAfterExit=yes förblir aktiv efter att kommandot avslutats, och en ny startbegäran gör ingenting eftersom systemd anser den redan startad. Det är en egenskap man designar kring, inte en defekt man kringgår med upprepade startanrop. Om åtgärden måste köras per anslutning behöver enheten en form som tillåter det.

After= ordnar enheter, och BindsTo= binder livslängder, men ingen av dem betyder 'starta om detta varje gång VPN:et återansluter'. En enhet bunden till tunneln stoppar när tunneln stoppar; den startar inte om sig själv när tunneln kommer tillbaka, om inte något startar den igen.

Testa tre återanslutningar, inte en

Kallstart, en full klientomstart och en mjuk återanslutning övar var sin väg. Den mjuka återanslutningen är den som avslöjar en saknad up-restart, en reducerad miljö eller en enhetsenhet som aldrig blev inaktiv. Kör alla tre och bekräfta båda riktningarna: tjänsten agerar när tunneln kommer upp, och den startar inte om vid orelaterade länkändringar som Wi-Fi-roaming.

Behåll en oberoende återställningsväg när den beroende tjänsten bär din egen administrativa åtkomst. En hook som startar om det du är ansluten genom är en ändring som kan låsa ute dig.