Starte en tjeneste på nytt ved OpenVPN up: hooks slår tun0.device

Å koble en avhengig tjeneste til tun0.device ser ut som å abonnere på tunnelen, og det er det ikke. En enhetsenhet gjenspeiler at grensesnittet finnes, noe som kan forbli sant gjennom en mislykket tilkobling og gjenoppkoblingen som følger. Tjenesten handler da på feil tidspunkt, eller aldri, avhengig av om grensesnittet forsvant i mellomtiden. Hooken som beskriver hendelsen du faktisk bryr deg om, er den OpenVPN kaller, ikke den systemd utleder.

Bestem hvilken betingelse tjenesten trenger før du velger utløseren, fordi de tre kandidatene ikke er utskiftbare.

Hva enhetsenheten faktisk følger

systemd oppretter en enhetsenhet fra kjernens syn på et nettverksgrensesnitt, så tun0.device blir aktiv når grensesnittet dukker opp og inaktiv når det fjernes. Med persist-tun holder en myk omstart grensesnittet på plass, så enheten flapper aldri og ingenting bundet til den utløses. Selv uten persistens sier enheten ingenting om ruter, DNS eller om den fjerne enden svarer.

Det gjør den til en dårlig stedfortreder for 'VPN-et er klart'. En lytter som bare trenger den lokale adressen, kan nøye seg med at grensesnittet finnes, mens en tjeneste som kaller en applikasjon på det fjerne nettverket trenger ruter og tilgjengelighet, som enhetsenheten ikke kan uttrykke.

up, route-up og up-restart betyr forskjellige ting

up kjøres etter at TUN/TAP-enheten er åpnet og grensesnittet er konfigurert, som er riktig tidspunkt for en lytter som binder den tildelte adressen. route-up kjøres etter at ruter er installert, underlagt enhver konfigurert ruterforsinkelse, og passer for arbeid som trenger ruterfasen fullført. Ingen av dem beviser at den fjerne applikasjonen svarer. Å velge mellom dem er et spørsmål om hva tjenesten trenger, ikke om hvilken hook som høres mer ferdig ut.

Med persist-tun gjenbruker omstarter enheten, så up kjøres ikke igjen med mindre up-restart er satt. Det alternativet aktiverer up-skriptet for den dokumenterte omstarts-livssyklusen, og miljøet er redusert sammenlignet med en første start. Et skript som antar det fulle miljøet, virker ved den første tilkoblingen og feiler ved den neste.

Send handlingen uten å vente på den

En hook som kaller systemctl restart synkront, kan gå i vranglås mot en enhet hvis rekkefølge venter på tunnelen. systemctl --no-block try-restart vpn-dependent.service setter jobben i kø og returnerer, noe som hindrer hooken i å blokkere tilkoblingen den reagerte på. try-restart virker bare på en kjørende enhet, mens restart også starter en inaktiv; velg bevisst, ikke av vane.

Køing er ikke verifisering. Hooken returnerer suksess så snart jobben er godtatt, så kontrollen må skje i journalen til målenheten eller i dens faktiske lyttertilstand.

Omstartspolicy bor i enheten, ikke i hooken

En oneshot-enhet med RemainAfterExit=yes forblir aktiv etter at kommandoen er ferdig, og en ny startforespørsel gjør ingenting fordi systemd anser den som allerede startet. Det er en egenskap man designer rundt, ikke en feil man omgår med gjentatte startkall. Hvis handlingen må kjøre per tilkobling, trenger enheten en form som tillater det.

After= ordner enheter, og BindsTo= binder levetider, men ingen av dem betyr 'start dette på nytt hver gang VPN-et kobler til igjen'. En enhet bundet til tunnelen stopper når tunnelen stopper; den starter ikke seg selv på nytt når tunnelen kommer tilbake, med mindre noe starter den igjen.

Test tre gjenoppkoblinger, ikke én

Kald oppstart, en full klientomstart og en myk gjenoppkobling øver hver sin vei. Den myke gjenoppkoblingen er den som avdekker en manglende up-restart, et redusert miljø eller en enhetsenhet som aldri ble inaktiv. Kjør alle tre og bekreft begge retninger: tjenesten handler når tunnelen kommer opp, og den starter ikke på nytt ved urelaterte lenkeendringer som Wi-Fi-roaming.

Behold en uavhengig gjenopprettingsvei når den avhengige tjenesten bærer din egen administrative tilgang. En hook som starter det du er tilkoblet gjennom på nytt, er en endring som kan låse deg ute.