Realm аутентификации VPN: какое пространство имён учётных записей побеждает?

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

Что выбирает realm

Шлюз получает имя пользователя и должен решить, где его проверять. Realm — это часть имени или атрибут рядом с ним, который выбирает базу данных: каталог, пул RADIUS, локальный файл учётных записей. NPS от Microsoft называет это именем realm и маршрутизирует по нему запросы подключения, а идентификатор сетевого доступа EAP несёт ту же идею как суффикс после знака at в RFC 7542. Оба являются селекторами, и ни один не решает, годятся ли учётные данные.

Это разделение даёт два очень разных отказа. Realm с правильной маршрутизацией и неправильным паролем даёт один отказ, тогда как realm, ведущий к неверной базе данных, может отклонить правильный пароль или принять чужой. Ни одна ошибка не упоминает realm, поэтому первая диагностика всегда одна и та же: выяснить, какая система ответила.

Синтаксис realm относится к развёртыванию. Одни службы хотят неквалифицированное имя плюс атрибут, другие хотят user@domain, а немногие ожидают форму с обратной косой чертой, о которой большинство руководств не упоминает.

Используйте форму, которую ожидает бэкенд

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

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

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

Проследите запрос через прокси

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

grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'

grep показывает, какие суффиксы существуют и на какой пул нацелен каждый. Вызов radtest отправляет имя с realm и намеренно неверный пароль, поэтому отказ доказывает, что выполнились и маршрутизация, и проверка учётных данных. Строки журнала вокруг этой попытки показывают, был ли суффикс удалён до прокси и какой домашний сервер его принял. Если журнал вообще не показывает совпадения realm, запрос так и не покинул локальный сервер, и проблема в суффиксе, а не в пароле.

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

Зафиксируйте попытку, не раскрывая её

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

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