Обмін IKEv2 проходить, а потім автентифікація зривається: де шукати

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

Перевірка 1: читайте етап, а не повідомлення

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

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

Перевірка 2: чию ідентичність перевірено

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

У термінах strongSwan це rightid на клієнті та власна ідентичність шлюзу з іншого боку, і невідповідність призводить до відмови ще до обговорення EAP.

Шлюз окремо може відхилити сертифікат клієнта, доказ володіння ключем або автентифікацію облікового запису, і ці три не є взаємозамінними. Скидання пароля користувача не поновлює сертифікат пристрою, а перевстановлення сертифіката пристрою не виправляє хибну ідентичність сервера. У разі збоїв сертифікатів спершу перевірте годинник, потім ланцюжок довіри, а далі очікуваний ідентифікатор; клієнт, чий годинник розходиться на кілька хвилин, не проходить перевірку терміну дії, схожу на збій довіри. swanctl --list-certs на обох кінцях показує, чим кожна сторона справді володіє.

Перевірка 3: якщо задіяно EAP

Клієнт і сервер мають домовитися про підтримуваний метод, а бекенд має прийняти надану ідентичність.

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

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

Перевірка 4: що відбувається після успішного входу

Коли IKE_AUTH завершується, узгодження CHILD_SA вирішує, які селектори трафіку буде встановлено, і саме там з'єднання може встановитися і все одно нічого не пропускати.

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

Перевірка 5: що передати в підтримку

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

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