Restart usluge na OpenVPN up: kuke pobjeđuju tun0.device

Povezivanje zavisne usluge na tun0.device izgleda kao pretplata na tunel, ali nije. Jedinica uređaja odražava da sučelje postoji, što može ostati točno kroz neuspješnu vezu i ponovno povezivanje koje slijedi. Usluga tada djeluje u pogrešnom trenutku, ili nikad, ovisno o tome je li sučelje u međuvremenu nestalo. Kuka koja opisuje događaj koji vas stvarno zanima jest ona koju poziva OpenVPN, a ne ona koju zaključuje systemd.

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

Što jedinica uređaja zapravo prati

systemd stvara jedinicu uređaja iz pogleda kernela na mrežno sučelje, pa tun0.device postaje aktivan kada se sučelje pojavi i postaje neaktivan kada se ukloni. Sa persist-tun, meki restart zadržava sučelje 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 odgovara li dalja strana.

To je čini lošim posrednikom za 'VPN je spreman'. Slušatelj kojem treba samo lokalna adresa može biti zadovoljan postojanjem sučelja, dok usluga koja 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 sučelje konfigurira, što je pravi trenutak za slušatelja koji veže dodijeljenu adresu. route-up se izvršava nakon instaliranja ruta, podložno bilo kojem konfiguriranom kašnjenju rute, i odgovara poslu kojem treba završena faza ruta. Nijedno ne dokazuje da daleka aplikacija odgovara. Biranje između njih pitanje je što usluga treba, a ne koja kuka zvuči dovršenije.

Sa persist-tun, restarti ponovno koriste uređaj, pa se up ne izvršava ponovno osim ako up-restart nije postavljen. Ta opcija omogućuje up skriptu za dokumentirani životni ciklus restarta, a njezino okruženje je smanjeno u usporedbi s prvim pokretanjem. 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 sinkrono 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 reagirala. 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 njezinu stvarnom stanju slušatelja.

Politika restarta živi u jedinici, ne u kuki

oneshot jedinica sa RemainAfterExit=yes ostaje aktivna nakon što njezina naredba izađe, a drugi zahtjev za pokretanje ne radi ništa jer systemd smatra da je već pokrenuta. To je svojstvo oko kojeg se projektira, a ne defekt koji se zaobilazi ponovljenim pozivima pokretanja. Ako se radnja mora izvršavati po vezi, jedinici treba oblik koji to dopušta.

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

Testirajte tri ponovna povezivanja, ne jedno

Hladno pokretanje, 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: usluga djeluje kada tunel ustane, i ne restartira se na nepovezane promjene veze poput Wi-Fi roaminga.

Zadržite neovisnu putanju oporavka kada zavisna usluga nosi vaš vlastiti administrativni pristup. Kuka koja restartira stvar kroz koju ste povezani promjena je koja vas može zaključati.