Як гібридна автентифікація IKEv1 переходить в автентифікацію користувачів IKEv2
Гібридний режим відокремлював доказ шлюзу від доказу користувача. Перехід на IKEv2 зберігає цей поділ, але змінює обмін, метод EAP і перевірки сертифіката.
Кожен старий профіль VPN, який спершу запитує сертифікат сервера, а потім ім'я користувача, несе дві події автентифікації в одному обміні, і ця форма переживає протокол, що її запровадив. Гібридний режим IKEv1 створено саме для цього: шлюз доводить себе відкритим ключем, а користувач доводить себе пізніше через XAuth. IKEv2 виражає ту саму двоетапну ідею іншим механізмом, і саме в цих відмінностях міграції зазнають невдачі. Жоден номер версії не перетворює одне на інше, а копіювання старих назв параметрів у новий профіль дає клієнт, який узгоджує параметри і потім нічого не автентифікує.
Що гібридний режим робив усередині IKEv1
У гібридному профілі відповідач підписує обмін першої фази своїм сертифікатом, а ініціатор навмисно не подає жодного. Доказ особи тому асиметричний, і саме це дало змогу шлюзу зберегти наявну PKI, а користувачам — свої каталогові паролі. Коли перша фаза завершена, XAuth виконується як запит і відповідь, що несуть атрибути імені користувача й пароля в уже зашифрованому каналі ISAKMP.
Зверніть увагу, де опиняється довіра. Сертифікат відповідає, до якого шлюзу прийшов клієнт; XAuth відповідає, який користувач хоче доступу. Жодне не замінює інше, а клієнт, налаштований приймати будь-який сертифікат сервера, мовчки відкинув першу відповідь. Мітку «гібридний» використовують і для агресивного режиму з наперед спільним ключем плюс XAuth — іншої схеми з тим самим досвідом користувача, тож читайте профіль, а не назву. Обидва варіанти походять із чернеток, що так і не стали стандартами, і тому два виробники можуть реалізувати гібридний режим і не взаємодіяти ні з ким.
Як IKEv2 доходить до тих самих двох доказів
IKEv2 поділяє роботу між IKE_SA_INIT і IKE_AUTH. Перший обмін узгоджує пропозиції та ключі без жодних ідентичностей; другий несе IDi, IDr і корисні навантаження AUTH. За EAP перше навантаження AUTH ініціатора виходить порожнім, відповідач автентифікується першим своїм сертифікатом і підписом, а далі розмова EAP точиться всередині повідомлень IKE_AUTH.
Механізм, що робить це безпечним, — ключовий матеріал. Успішний метод EAP експортує ключ сеансу, і підсумкове навантаження AUTH ініціатора обчислюється з нього, тож доказ користувача й ключі тунелю пов'язані. XAuth не має відповідника: його атрибути приходять після першої фази і нічого не додають до ключів. Саме цю прогалину каркас IKEv2 і мав закрити, і тому робочий вхід IKEv2 перевіряє сертифікат сервера, перш ніж щось запитати.
Цей порядок — ще й корисна діагностика. Коли клієнт скаржиться на облікові дані, не показавши вам сертифікат, він узагалі не виконує обмін EAP у IKEv2.
Тримайте три ідентичності окремо
Міграція йде не так, коли три ідентичності зливаються в одне поле. Є ідентичність шлюзу, яку перевіряє клієнт, зазвичай ім'я DNS у subject або SAN сертифіката. Є ідентичність користувача, подана в EAP, — можливо, доменний вхід, адреса або явний рядок ідентичності EAP. І є джерело авторизації, що зіставляє цього користувача з мережами та маршрутами.
Синтаксис swanctl у strongSwan робить поділ видимим: з'єднання задає remote { auth = pubkey } для шлюзу і local { auth = eap-mschapv2 } для користувача, а ідентичність EAP передається окремо.
Коли ідентичність користувача в новому профілі відрізняється від старих атрибутів XAuth, наприклад UPN замість короткого імені, сервер автентифікації бачить невідомого користувача, і збій виглядає як неправильний пароль. Перевіряйте рядок ідентичності раніше, ніж облікові дані.
Зіставте параметри і чекайте на пастки
Зіставлення коротке, і в кожному рядку є пастка, яка проявляється лише під час автентифікації.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Жоден із цих рядків не є простим перейменуванням. Навантаження конфігурації доставляє адреси й резолвери через типізований список атрибутів, тоді як простір атрибутів XAuth був власним винаходом; вважати їх взаємозамінними — так профіль і починає просити параметр, який шлюз ніколи не надішле.
Селектори трафіку заслуговують на окреме попередження. IKEv1 виражав цікавий трафік через ідентифікатори проксі, прив'язані до обміну quick mode, тоді як IKEv2 узгоджує селектори під час IKE_AUTH, і відповідач може їх звузити. Розбіжність дає встановлений IKE SA без child SA, який деякі клієнти радо показують як під'єднаний.
Вважайте старе з'єднання межею
RFC 9395 оголошує IKEv1 застарілим, тож старе гібридне з'єднання — межа сумісності з датою, а не фундамент. Запускайте обидва профілі паралельно на час переходу, бо важливий тест — не чи піднімається новий профіль, а чи потрапляє той самий користувач на тому самому пристрої до тих самих ресурсів.
Тримайте перевірку сертифікатів суворою до кінця. Щойно клієнт перестає подавати власний сертифікат, виникає спокуса послабити перевірку сервера, доки рукостискання не пройде, а це міняє єдиний залишок доказу на зелену позначку.
Запишіть чотири речі, перш ніж виводити старий профіль: метод EAP, рядок ідентичності, джерело авторизації та дату завершення підтримки.