keepalive în OpenVPN sau restart în systemd: care recuperează?

Trei lucruri diferite pot merge prost cu un tunel, și cer trei reacții diferite. Partenerul încetează să răspundă, procesul daemon moare sau aplicația din spatele tunelului încetează să deservească. O configurație care repornește serviciul la oricare dintre ele nu este o supraveghere atentă; este o singură acțiune dură aplicată unor defecțiuni fără legătură. Compararea a ceea ce poate observa cu adevărat fiecare mecanism face evidentă împărțirea muncii.

Trei defecțiuni care arată ca una

Tăcerea partenerului înseamnă că celălalt capăt a încetat să trimită, iar OpenVPN poate detecta asta singur pentru că deține bătăile inimii. Moartea procesului înseamnă că daemonul a ieșit, ceea ce managerul de servicii observă și OpenVPN nu poate. Defecțiunea aplicației înseamnă că tunelul este în regulă și ceva din spate nu, iar niciunul dintre celelalte două mecanisme nu are vreo cale să știe. Fiecare cere o reacție diferită și niciuna nu este același lucru cu a observa că tunelul este activ.

Acestea sunt semnale diferite din straturi diferite, iar fiecare are un proprietar care poate acționa fără să ghicească. Amestecarea lor produce un sistem care se repornește pe simptome pe care nu le poate interpreta.

Scrieți cele trei cazuri înainte de a schimba orice temporizator. Lista în sine arată de obicei că unui mecanism i se cere să le acopere pe toate trei.

La ce se extinde de fapt keepalive

Directiva keepalive este o prescurtare, iar extinderea variază în funcție de mod. Pe un server, keepalive 10 60 devine un ping local la fiecare zece secunde, un termen local de repornire de 120 de secunde și valorile 10 și 60 trimise clienților. Termenul serverului este dublat în mod deliberat pentru ca un client să aibă șansa de a reporni înainte ca serverul să renunțe. Citiți forma extinsă în configurația care rulează, nu prescurtarea din profil.

Această dublare este motivul pentru care orice descriere care susține că ambele capete repornesc după șaizeci de secunde este greșită. Ea explică și de ce cele două capete nu oscilează împreună când o cale se degradează.

Bătaia inimii este trafic de parteneri OpenVPN, nu o sondă ICMP către o gazdă publică. Un răspuns dovedește doar că capătul îndepărtat al tunelului este viu. Nu spune nimic despre baza de date sau serviciul web de care utilizatorul are cu adevărat nevoie.

Ce nu supraveghează Restart=on-failure

Citiți unitatea instalată înainte de a adăuga o suprascriere. Restart=on-failure răspunde la condiții documentate de defectare a procesului, ceea ce nu este același lucru cu supravegherea stării conexiunii. Nu se declanșează pentru că a început o reconectare internă, iar o ieșire curată are altă semantică decât o prăbușire.

Această distincție contează pentru că o repornire internă menține același proces în viață. Unitatea nu vede nimic, tunelul se recuperează singur, iar acesta este rezultatul corect.

Setați RestartSec și limitele de pornire în mod deliberat, altfel o buclă de prăbușiri va lovi poarta și va îngropa eroarea reală sub mesaje de repornire. O limită de repornire care se declanșează lasă unitatea în stare de defect, ceea ce este vizibil, în timp ce o buclă nelimitată nu este.

ping-restart și ping-exit nu sunt interschimbabile

ping-restart declanșează repornirea internă a OpenVPN și păstrează procesul. ping-exit încheie procesul la același tip de termen, ceea ce predă decizia managerului de servicii. Sunt mutual exclusive, iar alegerea celui de-al doilea schimbă cine deține recuperarea. Diferența este cine decide să încerce din nou și câtă stare supraviețuiește încercării.

Dacă alegeți ieșirea la termen, unitatea are nevoie de o politică de repornire și de o tratare a stării de ieșire care să se potrivească, altfel o defecțiune de vitalitate arată ca o oprire permanentă. Opțiunile de persistență pot păstra interfețele și rutele pe parcursul unei reporniri interne, dar nu pe parcursul unei ieșiri a procesului.

Alegeți un singur ciclu de viață per implementare și scrieți de ce. Un profil care poartă ambele directive este un profil care nu s-a decis.

Testați fiecare defecțiune ca propriul caz

Simulați un partener tăcut, un daemon ucis și o aplicație indisponibilă într-o fereastră aprobată, apoi verificați care recuperare s-a declanșat. Un partener tăcut ar trebui să producă o reconectare internă, un proces ucis o repornire a unității, iar o cădere a aplicației niciuna dintre ele. Când două cazuri produc aceeași acțiune, proprietatea este încă amestecată.

Recuperarea repetată nu este nici ea o reparație. Acreditările respinse sau doi clienți care împart un nume efectiv vor continua să se înlocuiască, iar temporizatoarele mai rapide fac doar acea oscilație mai rapidă.