Cum se măsoară durata de funcționare a clientului OpenVPN cu cârligele up și down

Un panou cere un număr pentru cât timp este conexiunea activă, iar OpenVPN nu îl oferă. Clientul știe când i-a urcat tunelul, dar numai dacă ceva înregistrează acel moment înainte de a se pierde starea sesiunii. Locul acceptat este cârligul up, iar valoarea care merită salvată este o secundă epoch brută, nu un șir formatat. Tot ce urmează este aritmetică, plus câteva reguli de ordine care decid dacă numărul rămâne corect.

Confirmați că cârligele chiar rulează

Dovediți că cârligul se declanșează înainte de a proiecta ceva în jurul lui. O configurație minimă de client are nevoie de script-security 2 și de căi explicite up și down; fără linia de securitate OpenVPN refuză să execute scriptul și spune asta fără ocolișuri. Adăugați up-restart și down-pre în același timp, astfel încât căile de repornire și de demontare să se comporte previzibil.

Faceți prima versiune a cârligului să adauge mediul său într-un fișier și să nu facă nimic altceva. Asta vă arată numele variabilelor pe care build-ul dumneavoastră le exportă cu adevărat, cum ar fi dev și script_type, în locul celor pe care le țineți minte dintr-o altă versiune. Rulați o conectare și o deconectare, apoi citiți fișierul. Dacă nu apare nimic, opriți-vă aici, pentru că un design cu marcaj de timp peste un cârlig care nu rulează niciodată va arăta ca o defecțiune de monitorizare săptămâni la rând.

Verificați sub ce utilizator rulează cârligul. Cu user și group setate, OpenVPN renunță la privilegii înainte de a rula scripturi, așa că un director în care root poate scrie poate fi închis pentru cârlig. Alegeți calea din perspectiva serviciului, nu a shell-ului dumneavoastră.

Înregistrați o singură valoare epoch și ștergeți-o deliberat

Cârligul up are nevoie de o singură linie, date +%s > /run/openvpn-client.started, cu calea ajustată pentru fiecare instanță. O valoare epoch evită mai târziu întrebările de limbă, fus orar și format, și este același număr pe care un agent de monitorizare îl poate compara cu propriul ceas.

Ștergerea contează la fel de mult ca scrierea. Cârligul down ar trebui să golească sau să elimine fișierul, iar down-pre face asta înainte de închiderea interfeței, ceea ce elimină fereastra în care fișierul descrie un tunel deja dispărut. up-restart apoi reîmprospătează marcajul la o repornire internă în loc să lase valoarea inițială pe loc. Fără acea pereche, o repornire după expirarea ping produce un număr care continuă să urce în timp ce tunelul se restabilește.

Alegeți un loc cu durata de viață potrivită. Un fișier sub /run dispare la repornire, ceea ce corespunde realității, în timp ce un fișier sub /tmp poate fi curățat imprevizibil, iar unul din directorul de configurare supraviețuiește într-un mod care induce în eroare. Setați permisiuni astfel încât doar utilizatorul serviciului și cititorul de monitorizare să îl poată citi.

Calculați durata de funcționare fără să vă bazați pe liniile din jurnal

Citiți secunda salvată, citiți secunda curentă, scădeți. Când fișierul lipsește sau este gol, răspunsul corect este că niciun tunel nu este activ, nu că durata de funcționare este zero, pentru că aceste două stări ar trebui să declanșeze alerte diferite. Păstrați secundele brute în datele de monitorizare și formatați zilele și orele în stratul de afișare. Un formator care rotunjește în interiorul exportatorului aruncă precizia de care cineva va avea nevoie în timpul unui incident.

Analizarea marcajelor de timp din jurnal este scurtătura tentantă și eșuează în trei moduri: formatul urmează orice opțiuni sunt setate, rotația elimină istoricul, iar reconectările apar ca sesiuni separate în loc de un singur tunel continuu. Cârligul înregistrează evenimentul o dată, în momentul în care se produce.

Când verificarea rulează pe alt host, trimiteți marcajul de timp în locul duratei, ca cititorul să aplice propriul ceas. Atunci un rezultat negativ mic se citește ca decalaj de ceas, nu ca un cârlig defect.

Acoperiți reconectările, repornirile și mai multe instanțe

Două tuneluri pe un singur host au nevoie de două fișiere, cu cheie pe numele instanței pe care serviciul îl folosește deja. O cale partajată înseamnă că cea mai recentă conexiune suprascrie ora de start a fiecărui profil, iar simptomul este un număr care sare înapoi când pornește un al doilea tunel.

Comportamentul la reconectare merită propriul test, pentru că acolo un design plauzibil raportează în liniște lucrul greșit. Forțați o repornire prin eliminarea partenerului sau prin trimiterea unui semnal procesului, apoi comparați starea interfeței cu fișierul. Marcajul de timp ar trebui să avanseze în momentul în care tunelul revine.

Pe partea de server, fișierul de stare poartă o valoare connected-since pentru fiecare client, care răspunde la o altă întrebare: când a văzut serverul ultima dată acel partener. Folosiți-o pentru verificare încrucișată, nu ca înlocuitor, deoarece dispare împreună cu sesiunea pe care o descrie. Niciuna dintre măsurători nu spune nimic despre sănătatea aplicației din spatele tunelului.

Rulați cele trei verificări care prind erorile de ordine

Testați o conectare normală, o reconectare forțată și o oprire curată, citind lista interfețelor și fișierul împreună după fiecare. Un marcaj încă prezent după o oprire curată, sau un fișier care afirmă un tunel ce nu apare în lista interfețelor, indică direct ordinea cârligelor. Rulați verificările ca utilizator al serviciului și cu căile serviciului, pentru că un shell root poate vedea alt fișier și poate da un răspuns greșit cu încredere. Apoi lăsați un sondor lent să citească fișierul și confirmați că nu scrie niciodată în el.

Un sondaj la fiecare șaizeci de secunde acoperă alertarea, și niciun cârlig nu ar trebui să se bazeze pe faptul că acel sondor este viu. Țineți cele două responsabilități separate și numărul rămâne de încredere când oricare parte este reimplementată.