IKEv1 с PSK, XAuth и OTP не требует одного сложного пароля. Он наслаивает общий ключ между узлами, пользовательский обмен и второй фактор, способ запроса которого определяет серверная часть. У каждого слоя свой владелец и своё сообщение об ошибке. Их смешение заставляет людей заново вводить одноразовый код в поле, где хранится групповой секрет.

Сопоставьте каждый запрос со слоем, который его требует, прежде чем ставить другой клиент или сбрасывать учётные данные.

Три секрета, три владельца

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

Запишите три столбца: владелец, срок жизни и сообщение об ошибке, которое порождает каждый из них. Инструмент диагностики — эта таблица, а не имена полей в клиенте.

LayerOwnerLifetime
Pre-shared keyPeer configurationUntil operators change it
XAuth credentialAuthentication backendPer session, per policy
One-time codeToken systemSingle use

PSK: узла, а не человека

В этой старой схеме общий предварительный ключ аутентифицирует пару шлюзов, поэтому вход пользователя никогда его не заменяет. Это ещё и значение, которое чаще всего оказывается неверным так, что выдаёт общую ошибку согласования вместо запроса. Когда туннель отказывает раньше, чем появляется хоть какой-то запрос пользователя, подозреваемые — ключ или предложения.

Учётные данные пользователя не исправят отказ первой фазы. Их ротация тратит единственные данные, которые можно безопасно ротировать, и укрепляет неверную теорию.

XAuth: старый пользовательский обмен

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

Проверьте, на какую серверную часть указывает профиль шлюза. Это говорит, что спросят у пользователя и что на самом деле меняет сброс пароля, и ни то ни другое не видно в профиле клиента.

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

Одни развёртывания просят отдельный одноразовый код после пароля, другие определяют совмещённый формат ввода с документированным разделителем. Существуют оба, и профиль перед вами решает, какой именно. Изобретать склейку потому, что она сработала в другом месте, — самый частый способ сжечь регистрационный токен. Решает это только документация самого шлюза.

Используйте документированный формат с клиентом, который способен завершить обмен, предлагаемый шлюзом.

Где кусается граница клиента

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

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

Диагностика без отключения фактора

Разделите в журнале этапы: согласование узлов, пользовательский обмен, результат второго фактора, затем выдача адреса и маршрута. Записывайте компонент и этап вместо того, чтобы пробовать код в каждом поле. Отключение фактора ради прохождения теста даёт туннель, который ничего не доказывает о развёртывании.

Храните регистрационные секреты и общий ключ в защищённом хранилище по процессу организации. Одноразовый код в постоянном файле — это фактор, который перестал быть фактором.

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