Repornim OpenVPN zilnic? Alegeți defecțiunea, nu ceasul

Moșteniți un job cron care repornește OpenVPN în fiecare zi la 04:10 și care ține lucrurile stabile de un an. De asemenea, deconectează un tunel sănătos la o oră fixă și nu face nimic pentru căderea care se întâmplă cu adevărat la prânz. O repornire după calendar este o decizie de întreținere. Recuperarea este alt design, cu un declanșator anume.

Trei forme de defecțiune cer trei proprietari diferiți. Alegeți mai întâi defecțiunea, iar mecanismul urmează.

Trei defecțiuni, trei proprietari

Un tunel poate fi activ în timp ce partenerul lui a dispărut: procesul rulează, interfața există și nimic util nu o traversează. Un proces poate fi mort în timp ce partenerul e în regulă, iar atunci doar ceea ce l-a pornit îl poate readuce. O aplicație din spatele tunelului poate fi stricată în timp ce și tunelul, și partenerul sunt sănătoase, iar repornirea clientului atunci lărgește căderea fără să atingă cauza. Separarea acestor trei cazuri este întreaga decizie.

Fiecare are propriul semnal și propriul proprietar. Vitalitatea aparține protocolului VPN, ciclul de viață al procesului aparține managerului de servicii, iar sănătatea aplicației aparține monitorizării cu un mandat îngust.

Ce poate și ce nu poate face o opțiune de vitalitate

keepalive este un ajutor care se extinde într-o pereche ping și ping-restart, după cum descrie referința opțiunilor de legătură, iar expirările pe care le produce nu sunt identice pe server și pe client. Valorile trimise de un server pot suprascrie și ce a configurat un client local, motiv pentru care o expirare care pare corectă într-un fișier local poate să nu fie cea în vigoare.

Asta îl face instrumentul potrivit pentru un partener pierdut și instrumentul greșit pentru un proces mort, fiindcă un proces încheiat nu își poate rula propriile temporizatoare. Nu spune nimic nici despre dacă o aplicație din spatele tunelului răspunde, pentru că schimbul are loc între cele două capete ale VPN. Copierea unei perechi de expirări dintr-o altă implementare fără a verifica rolul, întreruperile așteptate și comportamentul la reautentificare este felul în care un tunel stabil începe să tremure.

Ce deține managerul de servicii

Dacă daemonul iese, managerul care l-a pornit decide ce se întâmplă în continuare. O politică de repornire legată de eșec, cu o întârziere și o limită a ritmului de pornire, tratează o buclă de căderi fără a o transforma într-o fork bomb. Acele setări reacționează la rezultatele procesului și la expirări și nu detectează un proces viu dar inutil. Asta nu este o lipsă de acoperit cu o politică mai largă; este granița dintre ciclul de viață și vitalitate.

Proprietatea contează la fel de mult ca setările. O conexiune pornită de un manager de rețea de desktop ar trebui să păstreze aranjamentul de recuperare al acelui manager, iar adăugarea unei unități de serviciu concurente pentru aceeași interfață dă unui tunel doi proprietari. Alegeți unul și notați care este.

Când este legitimă o repornire programată

O repornire la o oră fixă poate fi o acțiune de întreținere rezonabilă: are proprietar, fereastră, instanță numită și o cale de acces independentă. Ceea ce nu poate fi este o politică generală de fiabilitate care deconectează pe toată lumea la o oră fixă.

Dacă repornirea există pentru a ocoli o scurgere cunoscută sau o stare blocată, spuneți asta în descrierea unității, altfel următoarea persoană o păstrează pentru totdeauna.

Testați cazurile care contează: partenerul dispare în timp ce procesul rămâne activ, procesul iese, o reîncercare are nevoie de acreditări noi, iar tunelul revine în timp ce aplicația rămâne stricată. Urmăriți ce componentă reacționează și ce stare lasă în urmă.

Întrebarea corectă nu este cât de des să repornim, ci ce ar trebui să observe defecțiunea mai întâi.