Чому завантажений тунель 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 гине саме на інтервалі зміни ключів, і це виглядає точно як збій таймера, доки хтось не прочитає пропозицію.

Порівняйте стару асоціацію з її наступницею та з обміном, який її породив. Зникнення ідентифікатора — рутинна заміна; відхилена пропозиція, відсутня відповідь або відсутність придатного стану наступника — інша подія з іншим власником. Збережіть ці докази, перш ніж щось змінювати, бо нотатки для конкретної версії, пропозиція партнера й узгоджені терміни життя — це те, що робить справу читабельною тиждень потому, після ротації журналів.

Доведіть оновлення, а не ховайте його

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

Висновок такої форми витримує перевірку, а змінене значення таймера, через яке з'єднання виглядало тихим півдня, — ні. Якщо зсунувся лише таймер, докази зсунулися разом із ним.