Repornirea unui serviciu la OpenVPN up: hooks bat tun0.device
Unitatea de dispozitiv urmărește interfața, nu conexiunea. Alegeți up sau route-up pentru condiția de care are nevoie serviciul, apoi trimiteți o repornire care nu blochează.
Conectarea unui serviciu dependent la tun0.device pare o abonare la tunel, și nu este. Unitatea de dispozitiv reflectă existența interfeței, ceea ce poate rămâne adevărat pe parcursul unei conexiuni eșuate și al reconectării care urmează. Serviciul acționează atunci în momentul greșit, sau niciodată, în funcție de faptul dacă interfața a dispărut între timp. Hookul care descrie evenimentul care vă interesează cu adevărat este cel pe care îl apelează OpenVPN, nu cel pe care îl deduce systemd.
Decideți de ce condiție are nevoie serviciul înainte de a alege declanșatorul, pentru că cei trei candidați nu sunt interschimbabili.
Ce urmărește de fapt unitatea de dispozitiv
systemd creează o unitate de dispozitiv din viziunea nucleului asupra unei interfețe de rețea, așa că tun0.device devine activă când interfața apare și inactivă când este eliminată. Cu persist-tun, o repornire blândă menține interfața pe loc, așa că unitatea nu clipește niciodată și nimic legat de ea nu este declanșat. Chiar și fără persistență, unitatea nu spune nimic despre rute, DNS sau dacă răspunde capătul îndepărtat.
Asta o face un substitut slab pentru „VPN-ul este gata”. Un ascultător care are nevoie doar de adresa locală se poate mulțumi cu existența interfeței, în timp ce un serviciu care apelează o aplicație din rețeaua îndepărtată are nevoie de rute și accesibilitate, pe care unitatea de dispozitiv nu le poate exprima.
up, route-up și up-restart înseamnă lucruri diferite
up rulează după ce dispozitivul TUN/TAP este deschis și interfața este configurată, care este momentul potrivit pentru un ascultător care leagă adresa atribuită. route-up rulează după instalarea rutelor, supus oricărei întârzieri de rută configurate, și se potrivește pentru munca ce necesită etapa de rute finalizată. Niciunul nu dovedește că aplicația îndepărtată răspunde. Alegerea între ele este o întrebare despre ce are nevoie serviciul, nu despre care hook sună mai terminat.
Cu persist-tun, repornirile reutilizează dispozitivul, așa că up nu rulează din nou decât dacă up-restart este setat. Acea opțiune activează scriptul up pentru ciclul de viață de repornire documentat, iar mediul său este redus comparativ cu o primă pornire. Un script care presupune mediul complet funcționează la prima conexiune și eșuează la următoarea.
Trimiteți acțiunea fără a o aștepta
Un hook care apelează systemctl restart sincron poate intra în impas cu o unitate a cărei ordonare așteaptă tunelul. systemctl --no-block try-restart vpn-dependent.service pune sarcina în coadă și revine, ceea ce împiedică hookul să blocheze conexiunea la care reacționa. try-restart acționează doar asupra unei unități care rulează, în timp ce restart pornește și una inactivă; alegeți deliberat, nu din obișnuință.
Punerea în coadă nu este verificare. Hookul returnează succes de îndată ce sarcina este acceptată, așa că verificarea trebuie să aibă loc în jurnalul unității țintă sau în starea reală a ascultătorului acesteia.
Politica de repornire trăiește în unitate, nu în hook
O unitate oneshot cu RemainAfterExit=yes rămâne activă după ce comanda sa se termină, iar o a doua cerere de pornire nu face nimic pentru că systemd o consideră deja pornită. Aceasta este o proprietate în jurul căreia se proiectează, nu un defect ocolit prin apeluri repetate de pornire. Dacă acțiunea trebuie să ruleze la fiecare conexiune, unitatea are nevoie de o formă care să permită asta.
After= ordonează unitățile, iar BindsTo= leagă duratele de viață, dar niciuna nu înseamnă „repornește asta de fiecare dată când VPN-ul se reconectează”. O unitate legată de tunel se oprește când tunelul se oprește; nu se repornește singură când tunelul revine, decât dacă ceva o pornește din nou.
Testați trei reconectări, nu una
Pornirea la rece, o repornire completă a clientului și o reconectare blândă exersează fiecare o cale diferită. Reconectarea blândă este cea care expune un up-restart lipsă, un mediu redus sau o unitate de dispozitiv care nu a devenit niciodată inactivă. Rulați toate trei și confirmați ambele direcții: serviciul acționează când tunelul urcă și nu se repornește la modificări de legătură nelegate, cum ar fi roamingul Wi-Fi.
Păstrați o cale de recuperare independentă când serviciul dependent poartă propriul dumneavoastră acces administrativ. Un hook care repornește lucrul prin care sunteți conectat este o schimbare care vă poate încuia afară.