IKEv1 з XAuth і OTP: чого саме вимагає кожен запит

IKEv1 з PSK, XAuth і OTP не вимагає одного складного пароля. Він нашаровує спільний ключ між вузлами, користувацький обмін і другий фактор, спосіб запиту якого визначає серверна частина. Кожен шар має свого власника і своє повідомлення про помилку. Їхнє змішування змушує людей заново вводити одноразовий код у поле, де зберігається груповий секрет.

Зіставте кожен запит із шаром, який його вимагає, перш ніж ставити інший клієнт або скидати облікові дані.

Три секрети, три власники

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

Запишіть три стовпці: власник, строк життя і повідомлення про помилку, яке породжує кожен із них. Інструмент діагностики — ця таблиця, а не назви полів у клієнті.

PSK: вузла, а не людини

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

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

XAuth: старий користувацький обмін

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

Перевірте, на яку серверну частину вказує профіль шлюзу. Це каже, що запитають у користувача і що насправді змінює скидання пароля, і ні те ні інше не видно в профілі клієнта.

OTP: що попросить серверна частина

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

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

Де кусається межа клієнта

Fortinet зазначає, що FortiClient 7.4.4 і новіші вже не підтримують IKEv1 для VPN IPsec, і це межа продукту та версії, а не повсюдне вилучення, як фіксує нотатка про сумісність FortiClient. Інші клієнти теж не взаємозамінні: OpenConnect і openfortivpn говорять конкретними протоколами шлюзу, а не довільними профілями IKEv1. Перевірте окремо версію IKE, режим PSK, підтримку XAuth і модель взаємодії встановленого клієнта. Клієнт, який підключається іншим способом, не довів початкову вимогу.

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

Діагностика без вимкнення фактора

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

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