Bakit gumagana ang IPsec tunnel mo hanggang sa unang CHILD SA key rekey

Bumangon ang tunnel, sumagot ang ping, at pumirma ang lahat. Makalipas ang apat na oras bumabagsak ang session, nag-log ang dalawang peer ng error sa proposal o key exchange, at ang unang hinala ay may nagbago sa network. Walang nagbago. Ang tunnel na nagdadala ng trapiko ay nagpatunay na nagkakasundo ang dalawang peer sa paraan ng pagpapatunay at pagprotekta sa unang child association, at wala itong napatunayan tungkol sa key exchange na hihilingin nila sa pag-renew. Nasa agwat ng dalawang pangyayaring iyon ang mismatch.

Ang konektado ay hindi ibig sabihin na tugma ang PFS settings

Sa IKEv2, nililikha ang unang child association habang nagaganap ang authentication exchange, at ang mga key nito ay hinango sa materyal na nagawa na ng IKE association. Walang hiwalay na Diffie-Hellman exchange para sa child na iyon, kaya ang patakarang nangangailangan nito sa pag-renew ay hindi sinusubok sa pagbangon.

Ang pag-renew ay ibang exchange. Kapag ni-renew ang key ng isang child association, maaaring magsagawa ang mga peer ng bagong key exchange sa grupong binanggit sa kanilang mga proposal, at iyon ang unang sandaling inihahambing ang mga setting ng grupo. Kaya ang dalawang peer na hindi nagkakasundo ay makakapagpatunay, makakapag-install ng child association at makakapagpadala ng trapiko, at pagkatapos ay mabibigo sa pag-renew.

Saan nagtatago ang mismatch sa string ng proposal

Sa strongSwan idinadagdag ang grupo sa proposal ng child, kaya ang string na tulad ng aes256gcm16-prfsha256-ecp256 ay mukhang pagpili ng encryption ngunit nagdadala rin ng pangangailangan sa key exchange. Ang peer na nag-aalok lamang ng aes256gcm16-prfsha256 ay walang ganoong pangangailangan, at nagtatagpo ang dalawang listahan sa encryption habang nagkakaiba sa exchange.

Basahin ang proposal ng child at ang proposal ng IKE bilang magkahiwalay na listahan. Ang grupong lumilitaw sa listahan ng IKE ay walang sinasabi tungkol sa listahan ng child, at ang pag-edit ng isa habang binabasa ang isa pa ang karaniwang paraan ng pagkakaligtaan nito.

Basahin ang kabiguan, hindi ang file na inedit mo

Hanapin ang notify na nagtapos sa exchange. Ang rekey ng child na nagbabalik ng «walang katanggap-tanggap na proposal» ay tumuturo sa mga listahan ng proposal; ang kahilingan sa pag-renew na hindi kailanman nakakatanggap ng sagot ay tumuturo sa landas o sa peer na tumigil sa pakikinig. Ang dalawang ito ay nangangailangan ng magkaibang pagwawasto, at pinaghihiwalay sila ng pananalita sa linya ng log.

Kumpirmahin ang tumatakbong configuration, hindi ang nasa disk. Ang file na na-save ngunit hindi na-load, o koneksyong muling binasa mula sa ibang include, ay gagawa ng mismatch na walang pag-edit sa nakikitang file ang makakatama.

Tatlong pangyayari na tinatawag na rekey ng key

Ang rekey ng key ng IKE association, ang muling pagpapatunay ng IKE at ang rekey ng key ng child association ay magkahiwalay na operasyon na may magkahiwalay na tuntunin sa proposal. Ang kabiguan na iniulat sa isa sa kanila ay walang direktang sinasabi tungkol sa iba, at ang log na naghahalo sa kanila ay mababasa na parang isang paulit-ulit na depekto gayong tatlo ito.

Pansinin kung aling pangyayari ang binabanggit ng peer, pagkatapos ay suriin ang mga proposal para lamang sa pangyayaring iyon. Baguhin ang isang listahan, i-reload at pilitin muli ang parehong pangyayari. Kung binabanggit ng log ang muling pagpapatunay, ang proposal ng IKE ang dapat basahin. Kung binabanggit nito ang rekey ng child, ang proposal ng child ang nagdadala ng grupong mahalaga.

Ang patayin ang pag-renew ay hindi pagwawasto

Ang pagtatakda ng oras ng rekey sa zero ay pinipigilan ang exchange na nabibigo, at ang tunnel ay nabubuhay hanggang sa gibain ito o mag-restart ang peer. Ang nabili mo ay key na mas matagal nabubuhay at mismatch na muling makikita mo sa panahon ng migration, audit o update mula sa vendor. Ganoon din sa mga haba ng buhay na hinila nang mas malayo sa patakarang inaasahan ng kabilang panig.

Sa halip, ihanay ang mga proposal. Pumili ng grupong ipinapatupad ng dalawang peer, ilagay ito sa proposal ng child sa magkabilang dulo, at panatilihin ang patakaran sa pag-renew sa saklaw na talagang kailangan ng organisasyon.

Patunayan ito sa exchange na nabigo

Paikliin ang oras ng rekey ng child sa isang maintenance window upang dumating ang pangyayari sa ilang minuto kaysa oras, o mag-trigger ng manu-manong rekey ng child. Pagkatapos ay panoorin ang matagumpay na pag-renew at kumpirmahin na nagpapatuloy ang trapiko sa pamamagitan nito, dahil ang bagong handshake na nag-i-install ng child association ngunit nagpapatumba sa daloy ng application ay ibang depekto.

Pagkatapos ay ibalik ang normal na haba ng buhay at itago ang dalawang talaan ng pangyayari, ang nabigo at ang matagumpay. Ang patunay na gusto mo ay nakakalampas ang koneksyon sa sarili nitong lifecycle, hindi na nakalampas ito sa ping.