Ang Pagpaikli ng DPD Timer Ay Hindi Nagpapabilis ng VPN Failover
Apat ang yugto ng pagbawi at isa lamang ang pinamamahalaan ng dead-peer timer. Sukatin nang hiwalay ang pagtukoy, pagpili ng peer, mga ruta at pagbawi ng aplikasyon.
Bumabagsak ang mga tunnel, tumatagal ng siyamnapung segundo ang pagbawi, at nakatakda sa sampu ang dead-peer timer, kaya ang timer ang sinisisi. Nilalaktawan ng pangangatwiran na iyon ang tatlong yugtong nangyayari pagkatapos ng pagtukoy at karaniwang kumukuha ng malaking bahagi ng oras. Napapansin ng liveness detection ang katahimikan; pagkatapos ay humahawak ng kani-kanilang pagkakataon ang pagpili ng peer, authentication, pag-install ng ruta at muling pagkonekta ng aplikasyon. Hindi kayang paikliin ng pagpaikli sa unang yugto ang iba, at makakadagdag ito ng kaguluhan sa sistemang hirap na hirap na.
Apat na yugto, isa sa kanila ang masusukat mo
Isulat ang pagbawi bilang apat na pangyayari na may timestamp. Nagiging nakikita ang pagkabigo: ang huling kapaki-pakinabang na protektadong trapiko at ang unang nabigong kahilingan. Tumutugon ang mekanismong may-ari: liveness detection, isang ruta monitor o iba pang nakadokumentong trigger. Nagiging magagamit ang alternatibo: pagpili ng peer, authentication, bagong asosasyon at rutang talagang nagdadala ng inilaan na trapiko. Nakakabangon ang aplikasyon: nagtagumpay ang bagong operasyon at ang nangyayari ay may tiyak na resulta.
Inilalarawan ng mga tuntunin ng liveness ng IKEv2 ang ebidensya tungkol sa peer at sa mga palitan nito, at wala itong sinasabi tungkol sa database o file service sa likod ng peer na iyon. Ang pagbasa sa liveness timeout bilang health check ng buong landas ang pagkakamaling nag-uumpisa sa paghahanap sa timer.
Bakit ang timer ang pinakamababang kawili-wiling numero
Ang mga naka-configure na halaga ay hindi mapagpapalit na yunit. Ang ilan ay pagitan ng muling pagsubok, ang ilan ay itaas na hangganan ng isang pagtatangka, at ang ilan ay tumatakbo nang sabay sa iba. Ang pagsasama-sama nila ay lumilikha ng numerong mukhang hula at kumikilos na parang tsismis. Basahin ang dokumentasyon ng field na kakalikutin mo, at tandaan kung alin sa tatlong uri ito.
Ang ibang yugto ay hindi timer. Ang backoff ng muling pagkonekta, interactive authentication prompt o kliyenteng muling nagsusuri ng configuration nito kapag nag-restart lamang ay maaaring mangibabaw sa pagkawala, habang bawat protocol timer ay maaliwalas na nakababa.
Sukatin ang yugtong talagang mabagal
Hulihin ang pagkabigo nang isang beses, may timestamp sa magkabilang panig, pagkatapos ihambing ang apat na pangyayari kaysa sa sariling counters ng protocol. Ang isang maayos na ginawang observation window ay mas mabuti kaysa isang buwang pag-tune.
ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"
Kung hindi kailanman tumugon ang alternatibong endpoint, walang pagbabago sa timer ang makakatulong, dahil ang hindi maabot ay hindi problema sa pagtukoy. Kung mabilis na nabuo ang bagong security state pero ang ruta ay nakaantig pa rin sa patay na landas, ang problema ay pag-install ng ruta at ang isa pang liveness tweak ay nagdaragdag lamang ng kaguluhan.
Dapat gamitin na ang alternatibo
Ang backup na tinukoy sa isang configuration ay hindi backup na gumagana. Dapat itong maabot mula sa kasalukuyang network ng kliyente, makapag-authenticate ng parehong pagkakakilanlan, at pinahihintulutang magdala ng parehong trapiko sa ilalim ng parehong patakaran. Kung may matuklasan kang isa sa tatlong puwang na iyon habang may pagkawala, nagiging walang kaugnayan ang usapan sa timer. Subukan ang alternatibo habang malusog ang primary, dahil iyon lang ang panahong mababasa mo ang parehong log nang magkatabi.
Ihanda ang alternatibo nang maaga, subukan ito nang sinasadya habang malusog ang primary, at itala kung alin sa apat na yugto ang kumukuha ng oras. Ang talaang iyon ang gumagawa sa susunod na pagbabago na sukat sa halip na haka-haka.
Kaguluhan ng failback at ang management path
Ang pagpapanumbalik ng primary ay hiwalay na desisyon. Ang agresibong failback ay makakaputol ng trabahong nakabangon na sa backup, at ang nanginginig na landas ay maaaring magmukhang hindi matatag na tunnel kapag ang tunay na depekto ay rutang patuloy na umiindayog sa pagitan ng dalawang pantay na opsyon.
Ang dalawang landas na pantay ang gastos na walang preperensya ang karaniwang pinagmumulan ng nakikitang indayog, dahil tumutugon ang bawat monitor sa pagpili ng isa. Magpasya kung aling landas ang ginusto sa normal na kondisyon, at gawing tahasan ang preperensyang iyon sa configuration kaysa iwanan ito sa pagkakasunod-sunod ng ruta. Tukuyin nang maaga ang gustong gawi sa failback at kung sino ang may-ari nito. Panatilihin ang dating setting at isang malayang management path, dahil ang pagbabagong nag-aalis ng sarili mong access habang may pagkawala ay ginagawang pagbisita sa site ang insidente sa network.
Pagkatapos ulitin ang parehong workload at ihambing ang parehong apat na timestamp. Ang mas maikling pagbawi na nag-iiwan pa rin sa aplikasyon na naghihintay sa parehong nawawalang ruta o login ay hindi pag-unlad, ito ay ibang numero sa parehong graph.