Een service herstarten bij OpenVPN up: hooks verslaan tun0.device

Een afhankelijke service aan tun0.device koppelen lijkt op een abonnement op de tunnel, en dat is het niet. Een apparaatunit weerspiegelt dat de interface bestaat, wat waar kan blijven tijdens een mislukte verbinding en de herverbinding die volgt. De service handelt dan op het verkeerde moment, of nooit, afhankelijk van of de interface tussendoor verdween. De hook die de gebeurtenis beschrijft die je echt aangaat, is degene die OpenVPN aanroept, niet degene die systemd afleidt.

Bepaal welke voorwaarde de service nodig heeft voordat je de trigger kiest, want de drie kandidaten zijn niet uitwisselbaar.

Wat de apparaatunit werkelijk volgt

systemd maakt een apparaatunit op basis van de kijk van de kernel op een netwerkinterface, dus tun0.device wordt actief wanneer de interface verschijnt en inactief wanneer die wordt verwijderd. Met persist-tun houdt een zachte herstart de interface op zijn plaats, dus de unit flappt nooit en niets dat eraan gebonden is wordt geactiveerd. Zelfs zonder persistentie zegt de unit niets over routes, DNS of de vraag of de verre kant antwoordt.

Dat maakt hem een slechte vervanger voor 'de VPN is klaar'. Een listener die alleen het lokale adres nodig heeft, kan tevreden zijn met het bestaan van de interface, terwijl een service die een toepassing op het verre netwerk aanroept routes en bereikbaarheid nodig heeft, wat de apparaatunit niet kan uitdrukken.

up, route-up en up-restart betekenen verschillende dingen

up draait nadat het TUN/TAP-apparaat is geopend en de interface is geconfigureerd, wat het juiste moment is voor een listener die het toegewezen adres bindt. route-up draait nadat routes zijn geïnstalleerd, onderworpen aan een eventuele geconfigureerde routevertraging, en past bij werk dat de routefase voltooid nodig heeft. Geen van beide bewijst dat de verre toepassing antwoordt. Kiezen tussen hen is een vraag naar wat de service nodig heeft, niet naar welke hook voltooid klinkt.

Met persist-tun hergebruiken herstarts het apparaat, dus up draait niet opnieuw tenzij up-restart is ingesteld. Die optie schakelt het up-script in voor de gedocumenteerde herstartlevenscyclus, en de omgeving ervan is beperkt vergeleken met een eerste start. Een script dat de volledige omgeving veronderstelt, werkt bij de eerste verbinding en faalt bij de volgende.

Verstuur de actie zonder erop te wachten

Een hook die systemctl restart synchroon aanroept, kan vastlopen tegen een unit waarvan de ordening op de tunnel wacht. systemctl --no-block try-restart vpn-dependent.service zet de taak in de wachtrij en keert terug, wat voorkomt dat de hook de verbinding blokkeert waarop hij reageerde. try-restart werkt alleen op een draaiende unit, terwijl restart ook een inactieve start; kies bewust, niet uit gewoonte.

In de wachtrij zetten is geen verificatie. De hook retourneert succes zodra de taak is geaccepteerd, dus de controle moet plaatsvinden in het journaal van de doelenheid of in zijn werkelijke listenerstatus.

Herstartbeleid woont in de unit, niet in de hook

Een oneshot-unit met RemainAfterExit=yes blijft actief nadat zijn commando is afgelopen, en een tweede startverzoek doet niets omdat systemd hem als al gestart beschouwt. Dat is een eigenschap waaromheen je ontwerpt, geen defect dat je met herhaalde startaanroepen omzeilt. Als de actie per verbinding moet draaien, heeft de unit een vorm nodig die dat toestaat.

After= ordent units, en BindsTo= bindt levensduur, maar geen van beide betekent 'herstart dit telkens wanneer de VPN opnieuw verbindt'. Een unit die aan de tunnel is gebonden, stopt wanneer de tunnel stopt; hij herstart zichzelf niet wanneer de tunnel terugkomt, tenzij iets hem opnieuw start.

Test drie herverbindingen, niet één

Koude start, een volledige herstart van de client en een zachte herverbinding oefenen elk een ander pad. De zachte herverbinding is degene die een ontbrekende up-restart, een beperkte omgeving of een apparaatunit onthult die nooit inactief werd. Voer alle drie uit en bevestig beide richtingen: de service handelt wanneer de tunnel omhoog komt, en hij herstart niet bij ongerelateerde linkwijzigingen zoals Wi-Fi-roaming.

Houd een onafhankelijk herstelpad aan wanneer de afhankelijke service je eigen beheerstoegang draagt. Een hook die herstart waar je door verbonden bent, is een wijziging die je buitensluit.