Reštartovať OpenVPN každý deň? Vyberte poruchu, nie hodiny

Dedíte cron úlohu, ktorá každý deň o 04:10 reštartuje OpenVPN, a už rok drží veci stabilné. Zároveň ale odpája zdravý tunel v pevnej hodine a nič nerobí s výpadkom, ktorý sa skutočne stane na obed. Reštart podľa kalendára je rozhodnutie o údržbe. Obnova je iný návrh s konkrétnym spúšťačom.

Tri podoby poruchy potrebujú troch rôznych vlastníkov. Najprv vyberte poruchu a mechanizmus vyplynie.

Tri poruchy, traja vlastníci

Tunel môže byť hore, zatiaľ čo jeho partner chýba: proces beží, rozhranie existuje a nič užitočné cez neho neprechádza. Proces môže byť mŕtvy, zatiaľ čo partner je v poriadku, a vtedy ho môže vrátiť len to, čo ho spustilo. Aplikácia za tunelom môže byť pokazená, zatiaľ čo tunel aj partner sú zdravé, a reštart klienta potom výpadok rozšíri bez toho, aby sa dotkol príčiny. Rozlíšenie týchto troch prípadov je celé rozhodnutie.

Každý má svoj signál a svojho vlastníka. Životnosť patrí protokolu VPN, životný cyklus procesu správcovi služieb a zdravie aplikácie monitoringu s úzkym mandátom.

Čo voľba životnosti dokáže a čo nie

keepalive je pomocník, ktorý sa rozvinie na dvojicu ping a ping-restart, ako opisuje prehľad volieb spojenia, a časové limity, ktoré vytvára, nie sú na serveri a klientovi rovnaké. Hodnoty, ktoré server tlačí, môžu tiež prepísať to, čo klient nastavil lokálne, a preto časový limit, ktorý v lokálnom súbore vyzerá správne, nemusí byť ten platný.

Preto je to správny nástroj pre strateného partnera a nesprávny nástroj pre mŕtvy proces, keďže ukončený proces nemôže spúšťať vlastné časovače. Tiež nič nehovorí o tom, či aplikácia za tunelom odpovedá, pretože výmena prebieha medzi dvoma koncovými bodmi VPN. Kopírovanie dvojice časových limitov z iného nasadenia bez kontroly roly, očakávaných prerušení a správania pri opätovnom overovaní je spôsob, akým stabilný tunel začne kmitať.

Čo vlastní správca služieb

Ak démon skončí, správca, ktorý ho spustil, rozhodne, čo bude ďalej. Politika reštartu viazaná na zlyhanie, so oneskorením a limitom rýchlosti spúšťania, zvládne slučku pádov bez toho, aby z nej urobila fork bombu. Tieto nastavenia reagujú na výsledky procesu a časové limity a nezachytia proces, ktorý je živý, ale nanič. To nie je medzera na zalepenie širšou politikou; je to hranica medzi životným cyklom a životnosťou.

Vlastníctvo je rovnako dôležité ako nastavenia. Spojenie spustené správcom siete na ploche by si malo ponechať spôsob obnovy tohto správcu, a pridanie konkurenčnej služby pre rovnaké rozhranie dá jednému tunelu dvoch vlastníkov. Vyberte jedného a zapíšte, ktorý to je.

Kedy je plánovaný reštart oprávnený

Časovo naplánovaný reštart môže byť rozumný údržbový zásah: má vlastníka, okno, pomenovanú inštanciu a nezávislý spôsob prístupu. Nemôže však byť všeobecnou politikou spoľahlivosti, ktorá navyše všetkých odpojí v pevnej hodine.

Ak reštart existuje preto, aby obchádzal známy únik alebo zaseknutý stav, napíšte to do popisu jednotky, inak si ho ďalší človek nechá navždy.

Otestujte prípady, na ktorých záleží: partner zmizne, zatiaľ čo proces beží ďalej, proces skončí, opakovaný pokus potrebuje nové prihlasovacie údaje a tunel sa vráti, zatiaľ čo aplikácia zostane pokazená. Sledujte, ktorý komponent zareaguje a aký stav po sebe zanechá.

Správna otázka nie je, ako často reštartovať, ale čo má poruchu zachytiť ako prvé.