OpenVPN keepalive o systemd restart: alin ang nakakabawi?

Tatlong magkaibang bagay ang maaaring mabigo sa isang tunnel, at tatlong magkaibang tugon ang kailangan nila. Tumitigil sa pagsagot ang peer, namamatay ang proseso ng daemon, o tumitigil sa paglilingkod ang application sa likod ng tunnel. Ang isang configuration na nagre-restart ng serbisyo sa alinman sa mga ito ay hindi maingat na pangangasiwa; isa itong blunt na aksyon na inilalapat sa magkakaibang pagkabigo. Ang paghahambing kung ano talaga ang napapansin ng bawat mekanismo ang nagpapalinaw sa paghahati ng trabaho.

Tatlong pagkabigo na mukhang isa

Ang katahimikan ng peer ay nangangahulugang tumigil sa pagpapadala ang kabilang dulo, at OpenVPN mismo ang makakadetekta nito dahil sa kanya ang heartbeat. Ang pagkamatay ng proseso ay nangangahulugang umalis ang daemon, na napapansin ng service manager at hindi kaya ng OpenVPN. Ang pagkabigo ng application ay nangangahulugang maayos ang tunnel at may isang bagay sa likod nito na hindi, at wala sa dalawang iba pang mekanismo ang paraan para malaman iyon. Bawat isa ay nangangailangan ng ibang tugon, at wala sa kanila ang katulad ng pagpansin na umaandar ang tunnel.

Iba't ibang signal ang mga ito mula sa iba't ibang layer, at bawat isa ay may may-ari na makakagalaw dito nang hindi nanghuhula. Ang paghahalo sa kanila ay gumagawa ng sistemang nagre-restart sa mga sintomas na hindi nito maiinterpreta.

Isulat ang tatlong kaso bago palitan ang anumang timer. Ang listahan mismo ay kadalasang nagpapakita na isang mekanismo ang hinihiling na sumakop sa lahat ng tatlo.

Ano talaga ang ine-expand ng keepalive

Ang direktibang keepalive ay shorthand, at nag-iiba ang expansion ayon sa mode. Sa isang server, ang keepalive 10 60 ay nagiging lokal na ping tuwing sampung segundo, lokal na restart timeout na 120 segundo, at mga value na 10 at 60 na ipinapadala sa mga client. Sinadya ang pagdoble ng server timeout upang magkaroon ang client ng pagkakataong mag-restart bago sumuko ang server. Basahin ang na-expand na anyo sa tumatakbong configuration, hindi ang shorthand sa profile.

Ang pagdobleng iyon ang dahilan kung bakit mali ang anumang paglalarawang nagsasabing nagre-restart ang dalawang dulo pagkatapos ng animnapung segundo. Ipinapaliwanag din nito kung bakit hindi sabay na nagwa-flap ang dalawang dulo kapag pumapangit ang isang path.

Ang heartbeat ay trapik ng peer ng OpenVPN, hindi ICMP probe sa ilang pampublikong host. Ang isang sagot ay nagpapatunay lamang na buhay ang dulong bahagi ng tunnel. Wala itong sinasabi tungkol sa database o web service na talagang kailangan ng user.

Ano ang hindi binabantayan ng Restart=on-failure

Basahin ang naka-install na unit bago magdagdag ng override. Ang Restart=on-failure ay tumutugon sa mga dokumentadong kondisyon ng pagkabigo ng proseso, na hindi katulad ng pagbabantay sa estado ng koneksyon. Hindi ito pumapalo dahil nagsimula ang isang panloob na muling pagkonekta, at may ibang kahulugan ang malinis na paglabas kaysa sa isang crash.

Mahalaga ang pagkakaibang iyon dahil pinapanatili ng panloob na restart na buhay ang parehong proseso. Wala itong nakikita ng unit, kusang bumabangon ang tunnel, at iyon ang tamang kinalabasan.

Itakda nang sadya ang RestartSec at mga limitasyon sa pagsisimula, kung hindi ay puro restart message ang ibabagsak ng crash loop sa gateway at ililibing ang tunay na error. Ang na-trigger na restart limit ay nag-iiwan ng unit na failed, na nakikita, samantalang ang walang limitasyong loop ay hindi.

Hindi mapapalitan ang ping-restart at ping-exit

Ang ping-restart ay nag-trigger ng panloob na restart ng OpenVPN at pinapanatili ang proseso. Ang ping-exit ay tinatapos ang proseso sa parehong uri ng timeout, na naglilipat ng desisyon sa service manager. Hindi sila maaaring gamitin nang sabay, at ang pagpili sa pangalawa ay nagbabago kung sino ang may-ari ng pagbangon. Ang pagkakaiba ay kung sino ang nagpapasyang subukan muli, at kung gaano karaming estado ang nakakaligtas sa pagtatangka.

Kung pipiliin mo ang exit-on-timeout, kailangan ng unit ang tugmang restart policy at paghawak ng exit status, kung hindi ay mukhang permanenteng paghinto ang liveness failure. Ang mga persistence option ay maaari ring panatilihin ang mga interface at ruta sa panloob na restart pero hindi sa paglabas ng proseso.

Pumili ng isang lifecycle bawat deployment at isulat ang dahilan. Ang profile na may dalawang direktiba ay profile na hindi pa nagpapasya.

Subukan ang bawat pagkabigo bilang sariling kaso

Gayahin ang tahimik na peer, pinatay na daemon at hindi available na application sa isang aprubadong window, pagkatapos ay tingnan kung aling pagbangon ang pumalo. Ang tahimik na peer ay dapat gumawa ng panloob na muling pagkonekta, ang pinatay na proseso ay restart ng unit, at ang pagkaantala ng application ay wala sa dalawa. Kapag dalawang kaso ang gumawa ng parehong aksyon, halo pa rin ang pagmamay-ari.

Ang paulit-ulit na pagbangon ay hindi rin pagkukumpuni. Ang tinanggihang kredensyal o dalawang client na nagbabahagi ng epektibong pangalan ay patuloy na magpapalitan, at ang mas mabilis na timer ay nagpapabilis lamang ng pag-flap na iyon.