Ваш SA IKEv2 піднято, але дочірнього SA немає: прочитайте обмін

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

Дві асоціації, дві задачі

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

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

Який рівень відмовив

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

Іноді відсутність дочірнього SA — це сам задум. SA IKE без дочірнього SA — це визначене розширення, яке застосовують там, де асоціацію даних треба створювати на вимогу, тому відсутність правильна, а дочірній SA з'являється, коли надходить відповідний трафік. Нотатки strongSwan про IKEv2 описують і стиль на вимогу, і налаштування пропозиції, від яких залежить перший випадок.

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

Потім запитайте про шлях даних

Щойно дочірній SA існує, на наступне питання відповідають лічильники. ip -s xfrm state повідомляє кількість пакетів і байтів на асоціацію, і дочірній SA, який нічого не несе, поки ви створюєте трафік, указує на зіставлення або маршрутизацію, а не на відсутню асоціацію. swanctl --list-sas друкує селектори дочірнього SA поруч із цими лічильниками, і саме це підтверджує, що пакет лежить усередині прийнятого набору.

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

Зіставте два кінці

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

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