RouterOS OpenVPN и NPS: задайте user-auth-method, а не auth

В RouterOS auth выбирает дайджест туннеля, а user-auth-method решает, как проверяется запрос RADIUS. Согласуйте второй параметр с политикой NPS.

RouterOS может доходить до NPS с входом OpenVPN и всё равно получать отказ, и обычная причина — два параметра, названия которых оба звучат как аутентификация. Один выбирает криптографический дайджест для туннеля; другой решает, как учётные данные пользователя передаются в RADIUS. Смена дайджеста никогда не превратит запрос PAP в MS-CHAPv2, сколько бы раз служба ни перезапускалась. Приведённый ниже чек-лист разделяет эти два параметра, а затем прослеживает один неудачный вход через политику NPS, которая его оценила.

Шаг 1: прочитайте оба параметра, прежде чем менять любой из них

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

/interface ovpn-server server print
/interface ovpn-server server export

Поле auth перечисляет дайджесты, такие как sha1 и sha256, и управляет HMAC, который аутентифицирует пакеты туннеля. Поле user-auth-method выбирает pap или mschap2 и решает, как маршрутизатор передаёт учётные данные пользователя в RADIUS. Смена дайджеста не может изменить второе поведение, поэтому тот же отказ сохраняется после любой правки первого.

Остановитесь здесь, если в вашем выпуске user-auth-method вообще не предусмотрен. Старые сборки RouterOS могут не предлагать его на сервере OpenVPN, и исправление относится к выпуску, который вы можете поддерживать, а не к команде, скопированной из более нового.

Шаг 2: найдите политику, которая действительно отклонила вход

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

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

Прочитайте в событии три вещи: имя подходящей политики, метод аутентификации и код причины. Политика, требующая MS-CHAPv2, отклоняет запрос PAP даже при правильном пароле, а политика, требующая доменную учётную запись, отклоняет локальную. Запись клиента RADIUS также должна совпадать с адресом источника маршрутизатора, иначе запрос отбрасывается ещё до обращения к любой политике. Ничего из этого не появляется в журнале OpenVPN.

Остановитесь здесь, если запрос так и не доходит до NPS. Это проблема общего секрета, адреса клиента или UDP 1812, и смена методов аутентификации её не исправит.

Шаг 3: измените один метод с обеих сторон

Если утверждённый проект — MS-CHAPv2, задайте его на маршрутизаторе и подтвердите, что подходящая политика его принимает. Измените одну сторону, повторите тест, затем измените другую; изменение обеих сразу не даст понять, какая имела значение.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

Не включайте на NPS все более слабые методы, чтобы ошибка исчезла. Внутренняя система должна иметь материал, который выбранный метод может проверить: MS-CHAPv2 требует доступа к паролю или домену, а политика не может выдумать этот материал. Расширение политики расширяет и то, что злоумышленник может попробовать против той же учётной записи. Запишите метод, имя политики и ссылку на изменение вместе, чтобы следующий человек унаследовал решение, а не догадку.

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

Шаг 4: проверьте три входа и одно разрешение

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

/log print where topics~"ovpn"
/radius monitor 0

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

Чек-лист завершён, когда настройка маршрутизатора и политика NPS называют один и тот же метод, разрешённый пользователь подключается в новой сессии, неверный пароль отклоняется, исключённый пользователь остаётся исключённым, а назначенный адрес соответствует предполагаемому пулу. Всё меньшее оставляет следующий вход на волю случая.

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