Да го рестартираме OpenVPN секој ден? Изберете го дефектот, не часовникот

Наследувате cron задача која го рестартира OpenVPN секој ден во 04:10 и која веќе една година ги држи работите стабилни. Таа исто така исклучува здрав тунел во фиксен час и не прави ништо за прекинот што навистина се случува на ручек. Рестартирањето по календар е одлука за одржување. Обновувањето е поинаков дизајн со конкретен тригер.

Три форми на дефект бараат три различни сопственици. Прво изберете го дефектот, а механизмот следи.

Три дефекти, три сопственици

Тунелот може да биде активен додека неговиот партнер го нема: процесот работи, интерфејсот постои и ништо корисно не поминува низ него. Процесот може да биде мртов додека партнерот е во ред, и тогаш само тоа што го започнало може да го врати. Апликацијата зад тунелот може да биде расипана додека и тунелот и партнерот се здрави, и тогаш рестартирањето на клиентот го проширува прекинот без да ја допре причината. Одвојувањето на тие три случаи е целата одлука.

Секој има свој сигнал и свој сопственик. Живоста им припаѓа на VPN протоколот, животниот циклус на процесот на менаџерот на услуги, а здравјето на апликацијата на мониторинг со тесен мандат.

Што може и што не може опцијата за живост

keepalive е помошник што се разградува во пар ping и ping-restart, како што опишува референцата за опциите на врската, а тајмаутите што ги создава не се исти на серверот и на клиентот. Вредностите што ги турка серверот можат да го надгласат и она што клиентот го поставил локално, и затоа тајмаут што изгледа точен во локална датотека може да не е оној што е на сила.

Тоа го прави вистинската алатка за изгубен партнер и погрешната алатка за мртов процес, бидејќи излезен процес не може да ги извршува своите тајмери. Исто така не кажува ништо за тоа дали апликацијата зад тунелот одговара, бидејќи размената се случува меѓу двата VPN крајни точки. Копирањето на пар тајмаути од друго распоредување без проверка на улогата, очекуваните прекини и однесувањето при повторна автентикација е начинот на кој стабилен тунел почнува да трепери.

Што поседува менаџерот на услуги

Ако демонот излезе, менаџерот што го започнал одлучува што следи. Политика за рестартирање врзана за дефект, со одложување и ограничување на стапката на стартување, се справува со циклус на падови без да го претвори во fork бомба. Тие поставки реагираат на резултатите на процесот и на тајмаутите и не откриваат процес што е жив но бескорисен. Тоа не е празнина што треба да се закрпи со поширока политика; тоа е границата меѓу животниот циклус и живоста.

Сопственоста е исто толку важна како поставките. Врската што ја започнал менаџер на мрежа на работна површина треба да го задржи распоредот за обновување на тој менаџер, а додавањето конкурентна услужна единица за истиот интерфејс му дава на еден тунел два сопственици. Изберете еден и запишете кој е.

Кога планираното рестартирање е оправдано

Рестартирање на определено време може да биде разумно дејство за одржување: има сопственик, прозорец, именувана инстанца и независен пат за пристап. Она што не може да биде е општа политика за доверливост која исто така ги исклучува сите во фиксен час.

Ако рестартирањето постои за да заобиколи познато истекување или заглавена состојба, кажете го тоа во описот на единицата, инаку следниот човек ќе го задржи засекогаш.

Тестирајте ги случаите што се важни: партнерот исчезнува додека процесот останува активен, процесот излегува, повторниот обид бара свежи акредитиви, и тунелот се враќа додека апликацијата останува расипана. Гледајте која компонента реагира и каква состојба остава зад себе.

Вистинското прашање не е колку често да се рестартира, туку што треба прво да го забележи дефектот.