Чому вхід у openfortivpn не вдається, коли ви вставляєте URL порталу

Збій виглядає як проблема з обліковими даними: openfortivpn запитує пароль, надсилає його, а шлюз відповідає відмовою або перенаправленням назад на сторінку входу. Тоді користувачі знову вводять пароль, пробують ім'я облікового запису з доменом і зрештою вставляють URL порталу з браузера в поле хоста. Саме цей останній крок перетворює невелику помилку конфігурації на заплутану.

Адреса порталу Fortinet, наприклад https://vpn.example.com/ext, несе кілька частин інформації одразу, і лише деякі з них належать клієнту VPN.

Кінцева точка та realm — окремі вхідні дані

openfortivpn очікує кінцеву точку у вигляді host або host:port, а також обліковий запис і, якщо розгортання використовує його, значення realm. Realm повідомляє шлюзу, яку політику автентифікації застосувати перед оцінкою облікового запису. Це окреме поле, а не суфікс, який клієнт витягує з URL.

Для розгортання, оператор якого підтверджує, що realm — ext, несекретний виклик виглядає так: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Ті самі значення належать у файл конфігурації як записи host, port, username і realm. Залиште пароль поза обома формами й дозвольте клієнту запитати його, щоб він не потрапив до історії оболонки чи у файл, доступний для читання всім. Друга спроба, поки перший клієнт ще тримає тунель, завершиться невдачею з причини, яка не має жодного стосунку до realm.

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

Сегмент шляху не є realm автоматично

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

Realm також не є ані суфіксом домену в імені користувача, ані регіоном, де розташований шлюз. Деякі розгортання хочуть alice, інші хочуть alice@corp, і саме realm вирішує, який з них прийме шлюз. Зміна формату облікового запису для компенсації неправильного realm зазвичай дає другу, менш інформативну відмову.

Не виправляйте помилку realm зміною хоста

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

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

Відокремте відхилений вхід від невдалого тунелю

Збої автентифікації та збої тунелю настають у різні моменти, і повідомлення різняться. Помилка розв'язання імені трапляється до будь-якого рукостискання TLS. Відмова TLS трапляється до надсилання облікових даних. Відмова realm або облікового запису повертається як відповідь на рівні HTTP від порталу. Лише після цих етапів починаються переговори PPP, і лише тоді з'являються проблеми з маршрутизацією та DNS.

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

Зберігайте значення там, де їх знайде наступний запуск

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

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