Сбой выглядит как проблема с учётными данными: 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 другого профиля.

Повторно проверьте одно соединение от начала до конца и подтвердите как применённую политику, так и доступ к ресурсу, который вам действительно нужен. Успешная аутентификация — это начало такой проверки, а не её конец.

Похожие статьи