Proč zaneprázdněný tunel IPsec obnovuje klíče dříve: časové a objemové limity

Přibližně každých padesát minut spadne tunel na vytíženém spoji na několik sekund a prvním podezřelým jsou hodiny. Asociace mohou skončit na časovém limitu nebo na počtu bajtů a hranice, která přijde první, je ta, která je odešle do důchodu. Na spoji s reálným provozem může objemový limit zasáhnout dlouho předtím, než vyprší nastavená hodina. Takže „příliš brzy“ je tvrzení o hodinách, ne o asociaci.

Počítejte to, co počítá asociace, ne rozhraní

Celkový počet bajtů na rozhraní, souhrnná propustnost na panelu a vlastní čítač asociace jsou tři oddělená čísla a jen jedno z nich se porovnává s limitem. Zaznamenávejte příchozí a odchozí asociaci odděleně s jejich identifikátory, aby se obnova klíčů, která se dotkne jednoho směru, ukázala jako směrová událost, a ne jako záhada. Čítač asociace také začíná při obnově klíčů znovu, a proto celkový údaj odebraný z rozhraní roste, zatímco hodnota, na které záleží, se resetuje.

Vyplatí se udělat výpočet jednou, aby řád velikosti přestal působit libovolně. Počítaný rozpočet jednoho gibibajtu vyčerpávaný stálými 128 mebibajty za minutu se spotřebuje za osm minut, a to je převod jednotek, ne měření vašeho tunelu. Pokud výsledné číslo leží hluboko pod časovým limitem, mechanismem je objem a žádné hlídání hodin interval nevysvětlí. Pokud leží hluboko nad ním, limit bajtů není váš spouštěč a hledání patří jinam.

Měkký a tvrdý práh jsou dvě různé události

Měkký práh žádá náhradu dlouho předtím, než tvrdý limit asociaci ukončí, a implementace na to, co jste nastavili, vrství vlastní rezervy a randomizaci. Proto pozorovaný interval téměř nikdy není kulaté číslo. Architektura IPsec popisuje životnosti vyjádřené časem a počtem bajtů se dvěma druhy prahů a platí ta dřívější expirace. Budete-li jeden vytištěný údaj o životnosti brát jako rozvrh, zmýlíte se o velikost rezervy.

Čtěte efektivní politiku z běžícího stavu, místo abyste ji odvozovali z čísla v souboru, protože rezerva patří implementaci, ne vašemu záměru. Odolejte natahování limitů k jejich maximu, abyste umlčeli symptom: tunel, který obnovuje klíče podle rozvrhu, se chová podle návrhu a delší životnost událost jen odkládá a kompromitovaný klíč ponechává použitelný déle. Když selže sama náhrada, limit je posel, ne vina.

Čtěte efektivní životnost z běžícího stavu

Na strongSwanu swanctl --list-sas vypisuje souhrn asociace s časy obnovy klíčů a životnosti, takže hodnota, kterou démon hodlá prosadit, je vidět bez hádání. Na hostiteli Linux bez pohledu démona ip xfrm state hlásí nastavené měkké a tvrdé limity bajtů a paketů vedle aktuálních čítačů. Ta dvě čtení odpovídají na různé otázky a obě stojí za to uchovat v tiketu.

swanctl --list-sas
ip -s xfrm state

Porovnejte vytištěný měkký práh s intervalem, který jste naměřili, protože náhrada začínající s rezervou pod tvrdým limitem je normální a náhrada, která nezačne nikdy, není. Pokud démon ukazuje jednu životnost a stav jádra jinou, díváte se na dvě vrstvy, které si neodpovídají, a to je samo o sobě zjištění.

Sledujte výměnu, která nahrazuje SA

Držte tři obnovy oddělené, protože selhávají různě: obnova klíčů IKE SA staví novou řídicí asociaci, obnova klíčů CHILD SA nahrazuje datovou asociaci a opětovná autentizace opakuje výměnu identity. V IKEv2 rozhoduje každá strana o svých vlastních životnostech, místo aby vyjednala jednu sdílenou hodnotu, takže výměna, kterou jste neiniciovali, je běžná. Neshoda v perfect forward secrecy je častou příčinou, proč nová child SA umírá právě v intervalu obnovy klíčů, a vypadá přesně jako závada časovače, dokud někdo nepřečte návrh.

Porovnejte starou asociaci s její nástupkyní a s výměnou, která ji vytvořila. Zmizení identifikátoru je rutinní náhrada; odmítnutý návrh, chybějící odpověď nebo nepřítomnost použitelného stavu nástupce je jiná událost s jiným vlastníkem. Uchovejte tyto důkazy, než cokoli změníte, protože poznámky specifické pro verzi, návrh protistrany a vyjednané životnosti jsou to, co učiní případ čitelným o týden později, poté co se logy protočí.

Dokažte obnovu, místo abyste ji skrývali

Přijměte nasazení tím, že projdete obnovou, kterou jste naplánovali, a ne tou, která se vám přihodí. Vynuťte jednu obnovu klíčů v rámci okna údržby, pak potvrďte, že oba směry poté přenášejí data a že výsledek aplikace je nezměněný, ne jen že indikátor tunelu je zelený. Zaznamenejte, který limit zasáhl a která výměna byla zapojena.

Závěr takového tvaru obstojí při prověrce, zatímco změněná hodnota časovače, která dala spojení na odpoledne tichý vzhled, neobstojí. Pokud se pohnul jen časovač, důkazy se pohnuly s ním.