Ponovni zagon storitve pri OpenVPN up: hooki premagajo tun0.device

Priključitev odvisne storitve na tun0.device je videti kot naročnina na tunel, a ni. Enota naprave odraža obstoj vmesnika, kar lahko ostane resnično skozi neuspešno povezavo in ponovno povezavo, ki sledi. Storitev nato deluje ob napačnem trenutku ali nikoli, odvisno od tega, ali je vmesnik vmes izginil. Hook, ki opisuje dogodek, ki vam je res pomemben, je tisti, ki ga kliče OpenVPN, ne tisti, ki ga sklepa systemd.

Odločite se, kateri pogoj storitev potrebuje, preden izberete sprožilec, ker trije kandidati niso zamenljivi.

Kaj enota naprave dejansko sledi

systemd ustvari enoto naprave iz pogleda jedra na omrežni vmesnik, zato tun0.device postane aktivna, ko se vmesnik pojavi, in neaktivna, ko je odstranjen. S persist-tun mehki ponovni zagon ohrani vmesnik na mestu, zato enota nikoli ne utripa in nič, kar je nanjo vezano, se ne sproži. Tudi brez trajnosti enota ne pove ničesar o poteh, DNS ali o tem, ali se oddaljena stran odziva.

To jo naredi slabega nadomestila za 'VPN je pripravljen'. Poslušalec, ki potrebuje samo lokalni naslov, se lahko zadovolji z obstojem vmesnika, medtem ko storitev, ki kliče aplikacijo v oddaljenem omrežju, potrebuje poti in dosegljivost, česar enota naprave ne more izraziti.

up, route-up in up-restart pomenijo različne stvari

up se zažene po tem, ko je naprava TUN/TAP odprta in vmesnik konfiguriran, kar je pravi trenutek za poslušalca, ki veže dodeljeni naslov. route-up se zažene po namestitvi poti, odvisno od vsake konfigurirane zakasnitve poti, in ustreza delu, ki potrebuje dokončano fazo poti. Nobeden ne dokazuje, da se oddaljena aplikacija odziva. Izbira med njima je vprašanje, kaj storitev potrebuje, ne kateri hook zveni bolj dokončan.

S persist-tun ponovni zagoni znova uporabijo napravo, zato up ne teče znova, razen če je nastavljen up-restart. Ta možnost omogoči skript up za dokumentirani življenjski cikel ponovnega zagona, njegovo okolje pa je zmanjšano v primerjavi s prvim zagonom. Skript, ki predpostavlja polno okolje, deluje pri prvi povezavi in spodleti pri naslednji.

Pošljite dejanje, ne da bi nanj čakali

Hook, ki sinhrono kliče systemctl restart, se lahko zaklene z enoto, katere vrstni red čaka na tunel. systemctl --no-block try-restart vpn-dependent.service doda opravilo v čakalno vrsto in se vrne, kar hooku prepreči, da bi blokiral povezavo, na katero se je odzival. try-restart deluje samo na delujočo enoto, medtem ko restart zažene tudi neaktivno; izbirajte namerno, ne po navadi.

Uvrščanje v čakalno vrsto ni preverjanje. Hook vrne uspeh takoj, ko je opravilo sprejeto, zato mora preverjanje potekati v dnevniku ciljne enote ali v njenem dejanskem stanju poslušalca.

Politika ponovnega zagona živi v enoti, ne v hooku

Enota oneshot s RemainAfterExit=yes ostane aktivna po koncu svojega ukaza, druga zahteva za zagon pa ne stori ničesar, ker systemd meni, da je že zagnana. To je lastnost, okoli katere se načrtuje, ne napaka, ki se ji izogne s ponovljenimi klici zagona. Če se mora dejanje izvajati ob vsaki povezavi, enota potrebuje obliko, ki to omogoča.

After= razvrsti enote, BindsTo= pa poveže življenjske dobe, a nobeno ne pomeni 'znova zaženi to vsakič, ko se VPN znova poveže'. Enota, vezana na tunel, se ustavi, ko se tunel ustavi; sama se ne zažene znova, ko se tunel vrne, razen če jo nekaj znova zažene.

Preizkusite tri ponovne povezave, ne ene

Hladni zagon, popoln ponovni zagon odjemalca in mehka ponovna povezava vsak vadi drugo pot. Mehka ponovna povezava je tista, ki razkrije manjkajoči up-restart, zmanjšano okolje ali enoto naprave, ki nikoli ni postala neaktivna. Zaženite vse tri in potrdite obe smeri: storitev deluje, ko tunel vstane, in se ne znova zažene ob nepovezanih spremembah povezave, kot je gostovanje Wi-Fi.

Ohranite neodvisno pot obnovitve, ko odvisna storitev nosi vaš lastni skrbniški dostop. Hook, ki znova zažene stvar, skozi katero ste povezani, je sprememba, ki vas lahko zaklene.