Сначала метод EAP: какой хеш пароля может использовать VPN
VPN проверяет сам секрет, а не веб-хеш. Прочитайте метод, а затем проверьте, что хранит хранилище, прежде чем обещать, что те же пароли продолжат работать.
У многих команд веб-вход работает, а VPN отвергает каждый пароль из той же таблицы. Веб-приложение сравнивает хеш, который оно вычислило само, тогда как туннель требует от клиента доказать владение секретом так, чтобы сервер мог это проверить. Это разные требования к хранимому материалу. Именно в разрыве между ними большинство таких проектов и застревает.
Сначала метод, потом схема
Запишите, какое доказательство требует выбранный метод, прежде чем смотреть на любую схему. Методу «запрос — ответ» нужен материал, из которого сервер может вычислить ожидаемый ответ, а это на практике означает пароль или совместимую производную форму. Методу, который несёт пароль внутри защищённого туннеля, нужен сам пароль у проверяющей стороны. Читайте документацию метода ради требования к проверяющему, а не ради конфигурации клиента, потому что требования клиента обычно простая часть.
Солёный хеш, созданный современным веб-фреймворком, не даёт ни того, ни другого. Он проверяет одно конкретное сравнение и не может быть обращён обратно в секрет, из которого возник.
«Запрос — ответ» не может использовать солёный хеш
MSCHAPv2 — это обмен «запрос — ответ», поэтому сервер никогда не получает пароль и не может сравнить сохранённую строку. Ему приходится выводить ожидаемый ответ из материала, который у него уже есть, и именно поэтому совместимые хранимые формы так узки. Значение bcrypt или Argon2 с солью на пользователя односторонне настолько, что полностью исключает обмен. Таблица ниже начинается с формы хранения, а не с названия метода, потому что ответ определяет именно форма хранения.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
Документация плагина SQL для strongSwan определяет собственную схему для конфигурации и учётных данных, и проект по-прежнему помечает этот плагин как экспериментальный. Ничто в ней не подстраивается под таблицу пользователей приложения и не угадывает, какая схема хеширования создала сохранённое значение. Поэтому реалистичные варианты — миграция в хранилище, которое шлюз может использовать, или служба аутентификации перед существующим хранилищем, способная выполнить обмен. Всё остальное — это коннектор со скрытым допущением внутри.
RADIUS переносит работу, а не требование
Делегирование EAP серверу RADIUS меняет место проверки и обычно улучшает след аудита. Оно не восстанавливает пароль из одностороннего хеша, поэтому службе аутентификации по-прежнему нужен материал, совместимый с методом, который она завершает. Команды узнают об этом после того, как построят путь через RADIUS и наткнутся на ту же стену на другом конце.
Там, где сервер RADIUS может читать каталог с совместимыми учётными данными, решение работает, а VPN-шлюз остаётся простым. Там, где не может, честный ответ — изменение регистрации, а не ещё один коннектор. Подготовка и отзыв принадлежат тому, кто владеет идентичностью, поэтому скопированная таблица без поддерживаемого процесса синхронизации — это второй жизненный цикл учётных данных, а не единый вход. Она расходится в первый раз, когда кто-то сбрасывает пароль только в одном месте, и это расхождение незаметно, пока учётная запись, существующая в обеих системах, не начнёт вести себя по-разному в каждой.
Ограничьте учётную запись, читающую каталог, только этим чтением и держите её отдельно от записи, которую шлюз использует для собственной конфигурации. Общая административная запись превращает схему только для чтения в гораздо более широкий радиус поражения.
Где должна жить учётная запись
Когда вопрос о материале решён, остаются две архитектуры. Шлюз может владеть небольшим хранилищем учётных данных, которое читает только он, или делегировать службе аутентификации, стоящей перед корпоративным каталогом.
Первая проще для осмысления и хуже для пользователя, которому остаётся второй пароль в обслуживании. Вторая сохраняет одну идентичность и добавляет зависимость от службы, которая теперь должна работать до того, как кто-либо подключится. Ни одна не ошибочна, но выбор стоит записать рядом с конфигурацией шлюза, иначе следующий инженер предположит, что выбрана другая. Что бы вы ни выбрали, две команды ниже показывают текущее состояние до его изменения.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsАутентификация учётной записи также не решает авторизацию. Членство в группах, состояние устройства и сетевое разрешение по-прежнему требуют явного сопоставления после того, как пользователь доказал требуемую идентичность. Соединение, которое безупречно аутентифицируется и ничего не авторизует, — это результат политики, а не дефект метода.