Защо натоварен IPsec тунел сменя ключовете рано: ограничения по време и обем

Приблизително на всеки петдесет минути тунел върху натоварена връзка пада за няколко секунди и първият заподозрян е часовникът. Асоциациите могат да приключат по ограничение за време или по брой байтове и която граница дойде първа, тя ги пенсионира. На връзка с реален трафик ограничението по обем може да задейства много преди зададеният час да изтече. Затова „твърде рано“ е твърдение за часовника, а не за асоциацията.

Бройте това, което брои асоциацията, а не интерфейса

Общият брой байтове на интерфейса, сумарната пропускателна способност на таблото и собственият брояч на асоциацията са три отделни числа и само едно от тях се сравнява с ограничението. Записвайте входящата и изходящата асоциация поотделно с техните идентификатори, за да изглежда смяната на ключове, която засяга една посока, като събитие по посока, а не като загадка. Броячът на асоциацията също започва отначало при смяна на ключове, затова общата стойност, взета от интерфейса, расте, докато значимата стойност се нулира.

Изчислението си струва да се направи веднъж, за да спре редът на величината да изглежда произволен. Бюджет от един гибибайт, изчерпван с постоянни 128 мебибайта в минута, се изразходва за осем минути и това е преобразуване на единици, а не измерване на вашия тунел. Ако полученото число е много под ограничението по време, механизмът е обемът и никакво следене на часовника няма да обясни интервала. Ако е много над него, ограничението по байтове не е вашият спусък и търсенето принадлежи другаде.

Мекият и твърдият праг са две различни събития

Мекият праг иска подмяна доста преди твърдото ограничение да приключи асоциацията, а реализациите добавят свои собствени резерви и рандомизация върху това, което сте задали. Затова наблюдаваният интервал почти никога не е кръгло число. Архитектурата на IPsec описва срокове на живот, изразени във време и брой байтове, с двата вида прагове, и по-ранното изтичане е определящото. Приемайте един отпечатан срок на живот като график и ще сгрешите с размера на резерва.

Четете ефективната политика от текущото състояние, вместо да я извеждате от число във файл, защото резервът принадлежи на реализацията, а не на намерението ви. Устоявайте на желанието да разтегнете ограниченията до максимума им, за да заглушите симптома: тунел, който сменя ключове по график, се държи както е проектиран, а по-дългият срок на живот само отлага събитието, като запазва компрометиран ключ използваем по-дълго. Когато самата подмяна се провали, ограничението е вестоносецът, а не вината.

Четете ефективния срок на живот от текущото състояние

На strongSwan swanctl --list-sas отпечатва обобщението на асоциацията с времената за смяна на ключове и живот, така че стойността, която демонът възнамерява да наложи, се вижда без догадки. На Linux хост без изглед от демон ip xfrm state отчита зададените меки и твърди ограничения за байтове и пакети до текущите броячи. Тези две показания отговарят на различни въпроси и двете си струва да останат в тикета.

swanctl --list-sas
ip -s xfrm state

Сравнете отпечатания мек праг с интервала, който сте измерили, защото подмяна, която започва при резерв под твърдото ограничение, е нормална, а подмяна, която никога не започва, не е. Ако демонът показва един срок на живот, а състоянието на ядрото — друг, виждате два слоя, които не са съгласни, и това само по себе си е находката.

Наблюдавайте обмена, който подменя SA

Дръжте трите подновявания отделно, защото те се провалят по различен начин: смяната на ключове на IKE SA изгражда нова управляваща асоциация, смяната на ключове на CHILD SA подменя асоциацията за данни, а повторното удостоверяване повтаря обмена на идентичност. В IKEv2 всяка страна решава собствените си срокове на живот, вместо да договаря една споделена стойност, затова обмен, който не сте започнали, е обичайно нещо. Несъответствие по perfect forward secrecy е честа причина ново child SA да умира точно на интервала за смяна на ключове и изглежда точно като повреда на таймер, докато някой не прочете предложението.

Сравнете старата асоциация с нейния наследник и с обмена, който я е създал. Изчезването на идентификатор е рутинна подмяна; отхвърлено предложение, липсващ отговор или липса на използваемо състояние на наследник е различно събитие с различен собственик. Запазете тези доказателства, преди да промените каквото и да е, защото бележките за конкретната версия, предложението на партньора и договорените срокове на живот са това, което прави случая четим седмица по-късно, след като журналите се завъртят.

Докажете подновяването, вместо да го скриете

Приемете внедряването, като преминете през подновяване, което сте планирали, а не през такова, което ви се случва. Принудете една смяна на ключове в прозорец за поддръжка, после потвърдете, че след това двете посоки пренасят данни и че резултатът на приложението е непроменен, а не само че индикаторът на тунела е зелен. Запишете кое ограничение е задействало и кой обмен е участвал.

Заключение с такава форма издържа проверка, а променена стойност на таймера, която е направила връзката тиха за следобед, не издържа. Ако се е преместил само таймерът, доказателствата са се преместили с него.