Bakit maagang nagpapalit ng susi ang abalang IPsec tunnel: mga limitasyon sa oras at volume

Mga bawat limampung minuto, bumabagsak ang isang tunnel sa abalang link nang ilang segundo, at ang unang pinaghihinalaan ay ang orasan. Maaaring magtapos ang mga association sa limitasyon ng oras o sa bilang ng bytes, at kung aling hangganan ang mauna ay iyon ang nagpapa-retire sa kanila. Sa isang link na nagdadala ng totoong trapiko, maaaring pumutok ang limitasyon sa volume bago pa matapos ang nakatakdang oras. Kaya ang «masyadong maaga» ay pahayag tungkol sa orasan, hindi tungkol sa association.

Bilangin ang binibilang ng association, hindi ang interface

Ang kabuuang bytes ng interface, ang pinagsamang throughput ng dashboard at ang sariling counter ng association ay tatlong magkaibang numero, at isa lamang sa kanila ang inihahambing sa limitasyon. Itala ang papasok at papalabas na association nang hiwalay kasama ang kanilang mga identifier, upang ang pagpapalit ng susi na dumadampi sa isang direksyon ay lumitaw bilang kaganapang may direksyon sa halip na misteryo. Nagsisimula ring muli ang counter ng association sa pagpapalit ng susi, kaya lumalaki ang kabuuang kinuha mula sa interface habang nire-reset ang halagang mahalaga.

Sulit gawin ang aritmetika nang isang beses upang tumigil ang order of magnitude sa pagmumukhang arbitraryo. Ang binilang badyet na isang gibibyte na nauubos sa tuloy-tuloy na 128 mebibyte kada minuto ay nauubos sa walong minuto, at iyon ay conversion ng unit, hindi pagsukat ng iyong tunnel. Kung ang resultang numero ay mas mababa nang malaki sa limitasyon ng oras, ang volume ang mekanismo at walang pagmamatyag sa orasan ang magpapaliwanag ng agwat. Kung ito ay mas mataas nang malaki, ang limitasyon sa bytes ay hindi ang iyong trigger at ang paghahanap ay kabilang sa ibang lugar.

Ang malambot at matigas na threshold ay dalawang magkaibang kaganapan

Humihingi ang malambot na threshold ng kapalit bago pa tapusin ng matigas na limitasyon ang association, at ang mga implementasyon ay nagdaragdag ng sarili nilang margin at randomization sa ibabaw ng anumang na-configure mo. Kaya ang naobserbahang agwat ay halos hindi kailanman bilang na bilog. arkitektura ng IPsec ay naglalarawan ng haba ng buhay na ipinahayag sa oras at bilang ng bytes na may dalawang uri ng threshold, at ang mas maagang pag-expire ang namamahala. Kung ituturing mong iskedyul ang isang nakalimbag na haba ng buhay, magkakamali ka nang sukat ng margin.

Basahin ang epektibong patakaran mula sa tumatakbong estado sa halip na hinuha ito mula sa numero sa isang file, dahil ang margin ay pag-aari ng implementasyon, hindi ng iyong intensyon. Labanan ang tuksong iunat ang mga limitasyon hanggang sa kanilang maximum upang patahimikin ang sintomas: ang tunnel na nagpapalit ng susi ayon sa iskedyul ay kumikilos ayon sa disenyo, at ang mas mahabang haba ng buhay ay nagpapaliban lamang ng kaganapan habang pinapanatiling magagamit ang isang nakompromisong susi nang mas matagal. Kapag nabigo ang kapalit mismo, ang limitasyon ang mensahero at hindi ang kasalanan.

Basahin ang epektibong haba ng buhay mula sa tumatakbong estado

Sa strongSwan, ipiniprinta ng swanctl --list-sas ang buod ng association kasama ang mga oras ng pagpapalit ng susi at buhay, kaya ang halagang balak ipatupad ng daemon ay nakikita nang walang hula. Sa isang Linux host na walang view ng daemon, iniuulat ng ip xfrm state ang naka-configure na malambot at matigas na limitasyon sa bytes at packet sa tabi ng kasalukuyang mga counter. Ang dalawang pagbasa ay sumasagot sa magkaibang tanong at parehong sulit itago sa ticket.

swanctl --list-sas
ip -s xfrm state

Ihambing ang nakalimbag na malambot na threshold sa agwat na sinukat mo, dahil ang kapalit na nagsisimula sa margin na mas mababa sa matigas na limitasyon ay normal at ang hindi kailanman nagsisimula ay hindi. Kung ang daemon ay nagpapakita ng isang haba ng buhay at ang kernel state ay nagpapakita ng iba, tinitingnan mo ang dalawang layer na hindi nagkakasundo, at iyon mismo ang natuklasan.

Bantayan ang palitan na pumapalit sa SA

Panatilihing hiwalay ang tatlong pag-renew, dahil nabigo sila sa magkaibang paraan: ang pagpapalit ng susi ng IKE SA ay bumubuo ng bagong control association, ang pagpapalit ng susi ng CHILD SA ay pumapalit sa data association, at ang reauthentication ay inuulit ang palitan ng pagkakakilanlan. Sa IKEv2, ang bawat peer ay nagpapasya ng sarili nitong haba ng buhay sa halip na makipagkasundo sa isang shared value, kaya ang palitan na hindi mo sinimulan ay karaniwan. Ang pagkakaiba sa perfect forward secrecy ay madalas na dahilan kung bakit namamatay ang isang bagong child SA nang eksakto sa agwat ng pagpapalit ng susi, at mukha itong eksaktong tulad ng sira ng timer hanggang may makabasa ng panukala.

Ihambing ang lumang association sa kahalili nito at sa palitan na gumawa nito. Ang pagkawala ng identifier ay karaniwang kapalit; ang tinanggihang panukala, nawawalang tugon o kawalan ng magagamit na estado ng kahalili ay ibang kaganapan na may ibang may-ari. Panatilihin ang ebidensiyang iyon bago baguhin ang anuman, dahil ang mga tala na tukoy sa bersyon, ang panukala ng peer at ang napagkasunduang haba ng buhay ang siyang nagpapabasa sa kaso makalipas ang isang linggo, pagkatapos ng pag-ikot ng mga log.

Patunayan ang pag-renew sa halip na itago ito

Tanggapin ang deployment sa pamamagitan ng pagdaan sa isang pag-renew na pinlano mo at hindi sa isang nangyayari sa iyo. Puwersahin ang isang pagpapalit ng susi sa loob ng maintenance window, pagkatapos ay kumpirmahin na ang dalawang direksyon ay nagdadala ng data pagkatapos at ang resulta ng application ay hindi nagbago, hindi lamang na berde ang indicator ng tunnel. Itala kung aling limitasyon ang pumutok at aling palitan ang nasangkot.

Ang konklusyong may gayong hugis ay nakalulusot sa pagsusuri, samantalang ang binagong halaga ng timer na nagpamukhang tahimik ang koneksyon sa isang hapon ay hindi. Kung ang timer lamang ang gumalaw, gumalaw din ang ebidensiya kasama nito.