I-restart ang OpenVPN araw-araw? Piliin ang kabiguan, hindi ang orasan
Ang pag-restart ayon sa kalendaryo ay maintenance, hindi recovery. Magpasya kung ang peer, ang proseso o ang aplikasyon ang nabigo, at ibigay sa layer na iyon ang trigger na kailangan nito.
Minana mo ang isang cron job na nagre-restart ng OpenVPN araw-araw sa 04:10, at isang taon na nitong pinananatiling stable ang lahat. Pero pinuputol din nito ang isang malusog na tunnel sa takdang oras at walang ginagawa sa pagkaantala na talagang nangyayari tuwing tanghalian. Ang pag-restart ayon sa kalendaryo ay isang desisyon sa maintenance. Ang recovery ay ibang disenyo na may partikular na trigger.
Tatlong hugis ng kabiguan ang kailangan ng tatlong magkaibang may-ari. Piliin muna ang kabiguan, at susunod ang mekanismo.
Tatlong kabiguan, tatlong may-ari
Maaaring nakaupo ang tunnel habang wala na ang peer nito: tumatakbo ang proseso, may interface, at walang kapaki-pakinabang na dumadaan dito. Maaaring patay ang proseso habang maayos ang peer, at sa ganoong kaso tanging ang nagpatakbo nito ang makakapagbalik dito. Maaaring sira ang aplikasyon sa likod ng tunnel habang malusog ang tunnel at ang peer, at ang pag-restart ng client ay nagpapalawak ng pagkaantala nang hindi hinahawakan ang sanhi. Ang paghihiwalay sa tatlong kasong iyon ang buong desisyon.
Bawat isa ay may sariling senyales at sariling may-ari. Ang pagiging buhay ay pag-aari ng protocol ng VPN, ang siklo ng buhay ng proseso ay pag-aari ng service manager, at ang kalusugan ng aplikasyon ay pag-aari ng monitoring na may makitid na mandato.
Ano ang kaya at hindi kaya ng opsyong pang-buhay
keepalive ay isang katulong na lumalawak sa pares na ping at ping-restart, gaya ng inilalarawan ng reference ng mga opsyon sa link, at ang mga timeout na ginagawa nito ay hindi pareho sa server at sa client. Ang mga halagang itinutulak ng server ay maaari ring mangibabaw sa itinakda ng client sa lokal, kaya ang timeout na mukhang tama sa lokal na file ay maaaring hindi ang umiiral.
Dahil dito, ito ang tamang kasangkapan para sa nawalang peer at maling kasangkapan para sa patay na proseso, dahil ang prosesong umalis ay hindi makakapagpatakbo ng sarili nitong timer. Wala rin itong sinasabi tungkol sa kung sumasagot ang aplikasyon sa likod ng tunnel, dahil ang palitan ay nangyayari sa pagitan ng dalawang dulo ng VPN. Ang pagkopya ng pares ng timeout mula sa ibang deployment nang hindi tinitingnan ang papel, mga inaasahang pagkaantala at pag-uugali sa muling pagpapatunay ay ang paraan kung paano nagsisimulang manginig ang isang stable na tunnel.
Ano ang pag-aari ng service manager
Kung lumabas ang daemon, ang manager na nagpatakbo nito ang magpapasya kung ano ang susunod. Ang patakaran sa pag-restart na nakabatay sa kabiguan, na may pagkaantala at limitasyon sa rate ng pagsisimula, ay humahawak sa crash loop nang hindi ito ginagawang fork bomb. Ang mga setting na iyon ay tumutugon sa mga resulta ng proseso at sa mga timeout, at hindi nila nadadetect ang prosesong buhay ngunit walang silbi. Iyon ay hindi puwang na tatapalan ng mas malawak na patakaran; iyon ang hangganan sa pagitan ng siklo ng buhay at pagiging buhay.
Ang pagmamay-ari ay kasinghalaga ng mga setting. Ang koneksyong sinimulan ng desktop network manager ay dapat panatilihin ang kaayusan sa recovery ng manager na iyon, at ang pagdaragdag ng karibal na service unit para sa parehong interface ay nagbibigay sa isang tunnel ng dalawang may-ari. Pumili ng isa at isulat kung alin.
Kailan lehitimo ang naka-iskedyul na pag-restart
Ang naka-time na pag-restart ay maaaring maging makatwirang pagkilos sa maintenance: may may-ari ito, may window, may pinangalanang instance at may malayang daan papasok. Ang hindi nito maaaring maging ay isang pangkalahatang patakaran sa pagiging maaasahan na naghihiwalay din sa lahat sa takdang oras.
Kung ang pag-restart ay umiiral para iwasan ang isang kilalang pagtagas o isang stuck na estado, sabihin ito sa paglalarawan ng unit, kung hindi ay panatilihin ito ng susunod na tao magpakailanman.
Subukan ang mga kasong mahalaga: nawawala ang peer habang nakaupo ang proseso, lumalabas ang proseso, ang muling pagtatangka ay nangangailangan ng bagong kredensyal, at bumabalik ang tunnel habang sira pa rin ang aplikasyon. Panoorin kung aling bahagi ang tumutugon at kung anong estado ang iniiwan.
Ang tamang tanong ay hindi kung gaano kadalas mag-restart, kundi ano ang dapat makapansin ng kabiguan muna.