Чому ваш тунель IPsec працює до першого оновлення ключа CHILD SA

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

Підключено не означає, що налаштування PFS збігаються

У IKEv2 перша дочірня асоціація створюється під час обміну автентифікації, а її ключі виводяться з матеріалу, який асоціація IKE вже виробила. Окремий обмін Diffie-Hellman для цієї дочірньої асоціації не відбувається, тому політика, що вимагає його під час оновлення, при підйомі не перевіряється.

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

Де невідповідність ховається в рядку пропозиції

У strongSwan група додається до дочірньої пропозиції, тому рядок на кшталт aes256gcm16-prfsha256-ecp256 виглядає як вибір шифрування, але також несе вимогу обміну ключами. Сторона, що пропонує лише aes256gcm16-prfsha256 такої вимоги не має, і два списки перетинаються в шифруванні, але розходяться в обміні.

Читайте дочірню пропозицію та пропозицію IKE як окремі списки. Група, що з'являється в списку IKE, нічого не говорить про дочірній список, а редагування одного під час читання іншого — звичний спосіб це проґавити.

Читайте збій, а не файл, який ви редагували

Знайдіть notify, що завершив обмін. Оновлення ключа дочірньої асоціації, яке повертає «немає прийнятної пропозиції», вказує на списки пропозицій; запит на оновлення, що ніколи не отримує відповіді, вказує на шлях або на сторону, яка перестала слухати. Ці два випадки потребують різних виправлень, і формулювання рядка журналу їх розділяє.

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

Три події, які всі називають оновленням ключа

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

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

Вимкнення оновлення — не виправлення

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

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

Доведіть це обміном, що провалився

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

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