Restartovanje servisa na OpenVPN up: kuke pobjeđuju tun0.device

Povezivanje zavisnog servisa na tun0.device izgleda kao pretplata na tunel, ali nije. Jedinica uređaja odražava da interfejs postoji, što može ostati tačno kroz neuspješnu vezu i ponovno povezivanje koje slijedi. Servis tada djeluje u pogrešnom trenutku, ili nikad, zavisno od toga da li je interfejs u međuvremenu nestao. Kuka koja opisuje događaj koji vas zaista zanima jeste ona koju poziva OpenVPN, a ne ona koju zaključuje systemd.

Odlučite koji uslov servis treba prije nego što odaberete okidač, jer tri kandidata nisu zamjenjiva.

Šta jedinica uređaja zapravo prati

systemd stvara jedinicu uređaja iz pogleda kernela na mrežni interfejs, pa tun0.device postaje aktivan kada se interfejs pojavi i postaje neaktivan kada se ukloni. Sa persist-tun, meki restart zadržava interfejs na mjestu, pa jedinica nikad ne flapa i ništa na nju vezano se ne pokreće. Čak i bez postojanosti, jedinica ne govori ništa o rutama, DNS-u ili tome da li dalja strana odgovara.

To je čini lošim posrednikom za 'VPN je spreman'. Slušalac kojem treba samo lokalna adresa može biti zadovoljan postojanjem interfejsa, dok servis koji poziva aplikaciju na dalekoj mreži treba rute i dostupnost, što jedinica uređaja ne može izraziti.

up, route-up i up-restart znače različite stvari

up se izvršava nakon što se TUN/TAP uređaj otvori i interfejs konfiguriše, što je pravi trenutak za slušaoca koji veže dodijeljenu adresu. route-up se izvršava nakon instaliranja ruta, podložno bilo kojem konfigurisanom kašnjenju rute, i odgovara poslu kojem treba završena faza ruta. Nijedno ne dokazuje da daleka aplikacija odgovara. Biranje između njih je pitanje šta servis treba, a ne koja kuka zvuči završenije.

Sa persist-tun, restarti ponovo koriste uređaj, pa se up ne izvršava ponovo osim ako up-restart nije postavljen. Ta opcija omogućava up skriptu za dokumentirani životni ciklus restarta, a njeno okruženje je smanjeno u poređenju s prvim startom. Skripta koja pretpostavlja puno okruženje radi na prvoj vezi i pada na sljedećoj.

Pošaljite radnju bez čekanja na nju

Kuka koja poziva systemctl restart sinhrono može doći u zastoj s jedinicom čiji redoslijed čeka tunel. systemctl --no-block try-restart vpn-dependent.service stavlja posao u red i vraća se, što sprječava kuku da blokira vezu na koju je reagovala. try-restart djeluje samo na pokrenutu jedinicu, dok restart pokreće i neaktivnu; birajte namjerno, a ne po navici.

Stavljanje u red nije provjera. Kuka vraća uspjeh čim se posao prihvati, pa se provjera mora dogoditi u dnevniku ciljne jedinice ili u njenom stvarnom stanju slušaoca.

Politika restarta živi u jedinici, ne u kuki

oneshot jedinica sa RemainAfterExit=yes ostaje aktivna nakon što njena komanda izađe, a drugi zahtjev za start ne radi ništa jer systemd smatra da je već pokrenuta. To je svojstvo oko kojeg se projektuje, a ne defekt koji se zaobilazi ponovljenim pozivima starta. Ako radnja mora da se izvršava po vezi, jedinici treba oblik koji to dozvoljava.

After= poređuje jedinice, a BindsTo= veže životne vijekove, ali nijedno ne znači 'restartuj ovo kad god se VPN ponovo poveže'. Jedinica vezana za tunel se zaustavlja kada se tunel zaustavi; ne restartuje se sama kada se tunel vrati, osim ako je nešto ponovo ne pokrene.

Testirajte tri ponovna povezivanja, ne jedno

Hladno podizanje, potpuni restart klijenta i meko ponovno povezivanje svaki vježba drugi put. Meko ponovno povezivanje je ono koje otkriva nedostajući up-restart, smanjeno okruženje ili jedinicu uređaja koja nikad nije postala neaktivna. Pokrenite sva tri i potvrdite oba smjera: servis djeluje kada tunel ustane, i ne restartuje se na nepovezane promjene veze kao što je Wi-Fi roaming.

Zadržite nezavisnu putanju oporavka kada zavisni servis nosi vaš vlastiti administrativni pristup. Kuka koja restartuje stvar kroz koju ste povezani je promjena koja vas može zaključati.