IKEv2 — це не одне рукостискання: IKE SA, автентифікація, далі CHILD SA
Відповідь шлюзу доводить доступність, а не особу. Простежте IKE_SA_INIT, IKE_AUTH і перший CHILD SA, потім перевірте, що має бути істинним до проходження трафіку.
Можливо, ви вважаєте, що з'єднання IKEv2 — це один обмін, який завершується шифруванням трафіку. Насправді їх щонайменше два, і перший нікого не автентифікує. Сторони починають з керуючих повідомлень, домовляються про криптографічні параметри, доводять особу і лише потім узгоджують стан, що переносить пакети застосунків. Цей порядок пояснює розбіжність, про яку люди постійно повідомляють: шлюз відповідає, клієнт показує з'єднання, а приватний застосунок усе одно виходить за тайм-аут. Нижче — що насправді робить кожен етап і що має бути істинним після нього.
Міф: якщо шлюз відповідає, ви підключені
Відповідь на перше повідомлення доводить, що кінцева точка доступна і готова говорити. Вона не доводить, що обліковий запис прийнято, ланцюг сертифікатів перевірено або встановлено якусь політику даних.
Ці відмови трапляються пізніше і дають інші симптоми. Відхилення сертифіката або збій EAP надходить уже після успішного першого обміну, тому ping на UDP 500 і зелений значок клієнта кажуть так мало.
IKE_SA_INIT: домовтеся про параметри, а не про особу
Перший обмін несе пропозиції для асоціації безпеки IKE: алгоритми шифрування та цілісності, псевдовипадкову функцію і групу Diffie-Hellman. Сторони також обмінюються nonce, і кожна виводить ключовий матеріал для IKE SA зі спільного секрету, який створюють ці значення. Ніщо в цьому обміні не встановлює, хто друга сторона. Він лише встановлює, що обидві сторони можуть обчислити ті самі ключі й згодні з пропозицією. Відповідач, якому не подобається жодна пропозиція, відхиляє обмін тут, тому розбіжність версії чи алгоритму виглядає як падіння сервера.
Створена тут IKE SA захищає всі подальші керуючі обміни. Це її робота, і вона відрізняється від захисту ваших пакетів.
IKE_AUTH: доведіть особу, потім побудуйте перший CHILD SA
Другий обмін несе особу. Із сертифікатами кожна сторона підписує своїм приватним ключем і подає ланцюг, який інша має перевірити; з EAP відповідач викликає ініціатора обраним методом. Саме тут нарешті виринають хибне ім'я сервера, прострочений сертифікат або відхилений пароль.
Зазвичай IKE_AUTH узгоджує і перший CHILD SA, тож захист даних домовляється в тому самому колі. Ініціатор пропонує селектори трафіку, відповідач звужує або відхиляє їх, а ключі шляху даних виводяться з IKE SA. Отже, один обмін може відмовити в двох геть різних місцях: в особі або в політиці. Читайте сповіщення чи помилку, а не загальний збій рукостискання: одне лікується сертифікатом, а інше — розбіжністю підмережі.
Дві SA, дві роботи
| Асоціація | Захищає | Поведінка часу життя |
|---|---|---|
| IKE SA | Керуючі обміни: перевироблення ключів, видалення, навантаження конфігурації | Оновлюється за власним графіком; шлях даних може пережити зміну |
| CHILD SA | Трафік застосунків, що збігається з селекторами трафіку | Оновлюється незалежно, часто частіше |
Їх розділення пояснює дві поведінки, схожі на помилки. Тунель може виглядати встановленим, поки у фоні збоїть перевироблення ключів, а CHILD SA можна замінити без втрати з'єднання клієнтом.
У strongSwan довідник з конфігурації IKEv2 і swanctl --list-sas показують обидва рівні, а ip xfrm state разом із ip xfrm policy показують, що ядро насправді встановило. Порівняння цих двох видів — найшвидший спосіб побачити, чи переговори завершилися, чи лише здавалися завершеними. Якщо демон перелічує CHILD SA, для якої ядро не має стану, встановлення тихо не вдалося. Якщо ядро тримає стан, про який демон не знає, ви бачите залишок попередньої спроби.
Що ще має бути істинним після підняття тунелю
Селектори трафіку визначають, які адреси охоплено. Якщо клієнт пропонує одну підмережу, а сервер очікує іншу, CHILD SA встановлюється, але не несе нічого корисного, і помилка виглядає як проблема маршрутизації, а не переговорів. Далі локальний стек має допомогти: пересилання ввімкнено там, де хост маршрутизує, маршрути в тунель, правила брандмауера, що пропускають декапсульовані пакети, і внутрішній резолвер, якщо задіяні приватні імена. Кожен із них відмовляє окремо, і жоден не лагодиться перезапуском демона IKE.
Тримайте журнал видимим під час діагностики: початковий обмін, потім перевірка особи, далі автентифікація користувача там, де вона застосовується, потім встановлення CHILD і нарешті трафік застосунку. Зупиняється той етап, який треба виправити, і пізніший збій маршрутизації ніколи не є приводом послабити вже пройдені перевірки особи.