Teenuse taaskäivitamine OpenVPN up korral: konksud võidavad tun0.device'i

Sõltuva teenuse ühendamine tun0.device-ga näib tunnelile tellimisena, kuid seda see ei ole. Seadmeüksus peegeldab liidese olemasolu, mis võib jääda tõeks läbi ebaõnnestunud ühenduse ja sellele järgneva taasühenduse. Seejärel tegutseb teenus valel hetkel või üldse mitte, sõltuvalt sellest, kas liides vahepeal kadus. Konks, mis kirjeldab sündmust, mis teid tegelikult huvitab, on see, mille kutsub välja OpenVPN, mitte see, mille tuletab systemd.

Otsustage, millist tingimust teenus vajab, enne kui valite päästiku, sest kolm kandidaati ei ole vahetatavad.

Mida seadmeüksus tegelikult jälgib

systemd loob seadmeüksuse kerneli vaatest võrguliidesele, seega tun0.device muutub aktiivseks, kui liides ilmub, ja mitteaktiivseks, kui see eemaldatakse. persist-tun korral hoiab pehme taaskäivitus liidese paigal, nii et üksus ei flapi kunagi ja miski sellega seotud ei käivitu. Isegi ilma püsivuseta ei ütle üksus midagi marsruutide, DNS-i ega selle kohta, kas kaugem ots vastab.

See teeb sellest halva asendaja 'VPN on valmis' jaoks. Ainult kohalikku aadressi vajav kuulaja võib rahulduda liidese olemasoluga, samas kui kaugvõrgus rakendust kutsuv teenus vajab marsruute ja kättesaadavust, mida seadmeüksus ei suuda väljendada.

up, route-up ja up-restart tähendavad erinevaid asju

up käivitub pärast TUN/TAP-seadme avamist ja liidese seadistamist, mis on õige hetk kuulajale, kes seob määratud aadressi. route-up käivitub pärast marsruutide paigaldamist, sõltudes seadistatud marsruudi viivitusest, ja sobib tööks, mis vajab marsruudietapi lõpetamist. Kumbki ei tõesta, et kaugrakendus vastab. Nende vahel valimine on küsimus sellest, mida teenus vajab, mitte sellest, milline konks kõlab valmimaks.

persist-tun korral kasutavad taaskäivitused seadet uuesti, seega up ei käivitu uuesti, kui up-restart pole seatud. See valik lubab up-skripti dokumenteeritud taaskäivituse elutsükli jaoks ja selle keskkond on vähendatud võrreldes esimese käivitusega. Skript, mis eeldab täielikku keskkonda, töötab esimesel ühendusel ja ebaõnnestub järgmisel.

Saatke toiming ilma selle ootamiseta

Konks, mis kutsub systemctl restart sünkroonselt, võib tupikuda üksuse vastu, mille järjestus ootab tunnelit. systemctl --no-block try-restart vpn-dependent.service paneb töö järjekorda ja naaseb, mis hoiab konksu blokeerimast ühendust, millele see reageeris. try-restart mõjub ainult töötavale üksusele, samas restart käivitab ka mitteaktiivse; valige teadlikult, mitte harjumusest.

Järjekorda panemine ei ole kontrollimine. Konks tagastab õnnestumise niipea, kui töö on vastu võetud, seega peab kontroll toimuma sihtüksuse päevikus või selle tegelikus kuulaja olekus.

Taaskäivituse poliitika elab üksuses, mitte konksus

oneshot-üksus RemainAfterExit=yes-ga jääb aktiivseks pärast oma käsu lõppemist ja teine käivituspäring ei tee midagi, sest systemd peab seda juba käivitatuks. See on omadus, mille ümber projekteeritakse, mitte defekt, millest mööda minnakse korduvate käivituskutsetega. Kui toiming peab toimuma iga ühenduse kohta, vajab üksus vormi, mis seda lubab.

After= järjestab üksusi ja BindsTo= seob eluead, kuid kumbki ei tähenda 'käivita see uuesti alati, kui VPN taasühendub'. Tunneliga seotud üksus peatub, kui tunnel peatub; see ei käivita end uuesti, kui tunnel naaseb, kui just miski ei käivita seda uuesti.

Testige kolme taasühendust, mitte ühte

Külmkäivitus, klientrakenduse täielik taaskäivitus ja pehme taasühendus harjutavad iga erinevat teed. Pehme taasühendus on see, mis paljastab puuduva up-restart, vähendatud keskkonna või seadmeüksuse, mis ei muutunud kunagi mitteaktiivseks. Käivitage kõik kolm ja kinnitage mõlemas suunas: teenus tegutseb, kui tunnel tõuseb, ja see ei käivitu uuesti seosetute lingimuudatuste korral nagu Wi-Fi-rändlus.

Hoidke sõltumatut taastetee, kui sõltuv teenus kannab teie enda haldusjuurdepääsu. Konks, mis käivitab uuesti selle, mille kaudu olete ühendatud, on muudatus, mis võib teid välja lukustada.