IKEv2: оновлення ключів проти повторної автентифікації — чому з’єднання падає пізніше

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

Дві операції, які ззовні виглядають схоже

Оновлення ключів замінює асоціації безпеки або ключовий матеріал у межах обміну, визначеного протоколом. Автентифікація не повторюється, тому особа, прийнята на початку сесії, просто переноситься далі.

Повторна автентифікація йде далі: вона встановлює нові автентифіковані відносини, а отже, облікові дані оцінюються знову. Усе, що минуло, було відкликано або змінилося в каталозі, стає видимим у той момент.

Що насправді замінює оновлення ключів

IKEv2 тримає два види асоціацій з окремими життєвими циклами. IKE SA захищає канал керування, а CHILD SA захищають реальний трафік. Оновлення однієї не є синонімом перепідключення клієнта.

Цей поділ пояснює знайомий сценарій: трафік іде добре, потім оновлюється CHILD SA і пропозиція більше не збігається, бо хтось тижні тому змінив фазу 2 на одній стороні. Зміна лежала там нешкідливо, доки оновлення її не задіяло.

Незбіги тривалості поводяться так само. Сторона, яка першою досягає своєї межі, починає обмін, а інша мусить його прийняти.

Що повторно оцінює повторна автентифікація

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

Тому продовження кожного строку виглядає виправленням і ним не є. Ви відклали перевірку замість того, щоб її пройти. Наступне оновлення приходить із тим самим дефектом і з коротшим вікном простою, щоб його помітити.

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

Прочитайте часові позначки, перш ніж щось змінювати

Зафіксуйте момент збою разом зі станом асоціації до і після. Якщо стару асоціацію замінено без обміну автентифікації, ви були на межі оновлення. Якщо безпосередньо перед збоєм з’являється обмін AUTH, ви були на повторній автентифікації.

strongSwan надає це як окремі налаштування: rekey керує оновленням ключів, reauth керує тим, чи відбувається нова автентифікація, а значення margin вирішують, наскільки заздалегідь до завершення починається кожна. документація щодо оновлення ключів описує цю взаємодію, і її варто прочитати, перш ніж копіювати строк із повідомлення на форумі.

Відрізняйте все це від звичайної втрати мережі. Розірване з’єднання дає подію виявлення мертвого партнера або шторм повторних передач, а не чистий обмін із відповідними пропозиціями.

Змініть те, що зламалося

Відмова в облікових даних вимагає виправити проблему особи: оновіть сертифікат, відновіть обліковий запис, повторно зареєструйте фактор. Незбіг пропозиції або строку вимагає порівняти параметри з обох боків.

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

Перевірте контрольоване оновлення

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

Успішний перший вхід нічого з цього не тренує. Життєвий цикл після нього — це місце, де такі розгортання справді ламаються.