Nananatiling bagsak ang strongSwan pagkatapos ng reboot ng peer: ibalik ang isang tunnel

Nag-reboot ang remote na gateway, bumabalik sa loob ng isang minuto, at patuloy na tumatakbo ang lokal na strongSwan daemon habang bagsak pa rin ang tunnel. Isang cron job na nag-grep ng ESTABLISHED at nagre-restart ng daemon ang tuluyang magtatakip doon, at puputulin din nito ang bawat walang kaugnayang tunnel sa makina habang maaaring makaligtaan ang mismong nabigo. Ang pagbawi ay kabilang sa koneksyon na dapat bumalik, na ipinahayag sa mga setting na nakakaligtas sa isang reload. Inihahanda ito ng runbook na ito para sa isang koneksyon at pinapatunayan ang resulta sa pangalan.

Iwanan ang pangkalahatang restart, itago ang mga ebidensya nito

Ang restart ng daemon ay may dalawang tiyak na depekto: sinisira nito ang estado ng bawat koneksyon, at wala itong sinasabi tungkol sa kung aling kaganapan ang tunay na nabigo. Ang tekstong status na iyong ginrep ay maaaring galing sa ibang koneksyon, habang ang kailangang child ay nakaupo nang walang ginagawa dahil walang nag-trigger dito.

Basahin ang mga nakargang koneksyon at ang mga aktibong asosasyon bago baguhin ang anuman, upang mayroon kang larawan bago para ihambing kapag bumalik ang peer.

swanctl --list-conns
swanctl --list-sas

Ilagay ang pagsisimula at mga pagtatangka muli sa koneksyong bumabalik

Sa isang deployment na swanctl.conf, ang mga setting na ito ay nasa antas ng koneksyon at child kaysa sa isang pangkalahatang patakaran. Ang fragment sa ibaba ay halimbawa mula sa panig ng initiator na ipinapalagay na tama na ang mga proposal, authentication at selector.

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

Ang start_action ang nagpapasya kung ano ang nangyayari kapag nakarga ang child: ang start ay nagsisimula agad, samantalang ang trap ay naglalagay ng patakaran na nag-trigger ng pagsisimula kapag may lumabas na tugmang trapiko. Ang pagsulat ng trap|start ay nangangailangan ng strongSwan 5.9.6 o mas bago, kaya suriin ang bersyon bago kopyahin ang linya. Ang dpd_action=restart ay humihiling ng bagong negosasyon kapag idineklarang patay ang peer, at ang keyingtries=0 sa antas ng koneksyon ay nagpapahintulot ng karagdagang pagtatangka hanggang sa tagumpay o permanenteng error. Sa ilalim ng IKEv2, ang dpd_timeout ay walang anumang epekto, dahil ang ordinaryong muling pagpapadala ang nagpapasya kung kailan hindi tumutugon ang peer.

Ang pagkaantala sa halimbawang iyon ay panimulang punto at hindi pangkalahatang takda. Piliin ito batay sa tagal ng reboot ng peer at kung gaano karaming muling pagpapadala ang handa mong tiisin.

Alamin kung saang kaganapan ka bumabawi

Tatlong pagkabigo ang magkapareho sa isang dashboard at nangangailangan ng iba't ibang setting. Ang paunang koneksyon na hindi kailanman umangat ay problema sa configuration o abot. Ang peer na tumigil sa pagsagot ay ang kaso ng DPD. Ang child na tahasang isinara ng peer ay kaganapan ng patakaran na may sariling close_action, na hindi kailanman napapansin ng DPD. Ang pagbasa ng log sa paligid ng pagkaantala ay nagsasabi kung alin sa tatlo ang mayroon ka, at binabago ng sagot ang pagtatama.

Huwag magdagdag ng agresibong muling pagsisimula sa koneksyong sadyang isinasara ng mga operator para sa maintenance, kung hindi ay muling lalabas ang tunnel sa gitna ng window. Para sa mga disenyong on-demand, sapat na ang itinagong trap, dahil ang tugmang trapiko ay muling nagtatatag ng child nang walang anumang timer.

I-verify sa pangalan, hindi sa status ng daemon

Basahin ang koneksyon at ang child nito sa pangalan habang bagsak pa ang peer, pagkatapos ay muli kapag bumalik ito; ang pagkakaiba ng dalawang output na iyon ang ebidensya.

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

Pagkatapos, kumpirmahin ang serbisyo at hindi ang asosasyon. Ang bagong child security association at isang matagumpay na kahilingan sa pribadong destinasyon sa likod nito ang pares ng katotohanang mahalaga, at ang tumatakbong daemon na may malusog na walang kaugnayang tunnel ay hindi nagpapatunay ng alinman.

Kung hindi kailanman nagsisimula ang child, tingnan kung eksaktong tumutugma ang test traffic sa mga naka-configure na selector, kasama ang protocol at port. Kung nagsisimula ito at nabigo, basahin ang error sa authentication o proposal sa halip na itago ito sa likod ng walang katapusang loop, dahil ang keyingtries=0 ay masayang uulitin ang permanenteng pagtanggi magpakailanman.

I-load ang pagbabago sa isang window at muling subukan

Ang reload ay mas ligtas kaysa sa restart ng daemon, at hindi pa rin ito libre: ang pagpapalit o pag-unload ng child ay maaaring magsara ng nasimulang asosasyon o magpabagsak ng trap nito.

Mag-load sa panahon ng maintenance window, itago ang dating file, at kumpirmahin na lumalabas ang koneksyon sa mga setting na nilayon mo at hindi sa mga default.

swanctl --load-conns
swanctl --list-conns

I-rollback sa pamamagitan ng pagpapanumbalik ng dating file at muling pag-load nito, pagkatapos ay ulitin ang parehong dalawang command. Ang tunnel na bumabalik lamang pagkatapos ng restart ng daemon ay hindi naayos, na-reset ito.