Почему правка файла .ovpn не включает MFA на сервере

Вы добавляете auth-user-pass в профиль, переподключаетесь, и клиент запрашивает имя пользователя и пароль. Кажется, что MFA включён. Затем вы вводите код с чужого аккаунта или код, истёкший десять минут назад, а туннель всё равно поднимается. Это и есть симптом: клиент изменился, сервер нет. Одноразовый пароль является фактором только тогда, когда проверяющий на сервере решает, действителен ли он для той личности, которая его требует.

Запрос доказывает лишь то, что клиент спросил, и ничего больше

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

Установка приложения-аутентификатора на телефон тоже не создаёт этой связи. Проект Google Authenticator PAM — это компонент проверки OTP, который может стоять за OpenVPN; это не способ приклеить вход в аккаунт Google к импортированному профилю.

Регистрация — та часть, которую профиль выполнить не может

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

Поэтому оператору нужен процесс регистрации, привязывающий правильное зерно к правильной личности VPN, а также проверенный путь замены для потерянного телефона. Если разрешить пользователям загружать файл, названный их именем, регистрация превращается в возможность захвата аккаунта, и шифрование загрузки этого не меняет.

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

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

Прочитайте стек PAM, чтобы понять, что действительно требуется

Строка вроде account required pam_permit.so не реализует право доступа к учётной записи и не добавляет фактор. Она разрешает этот этап управления учётными записями PAM, что является утверждением об этапе, а не о ваших пользователях.

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

Согласуйте взаимодействие клиента с архитектурой сервера

auth-user-pass

Эта директива запрашивает ввод имени пользователя и пароля. Она не настраивает PAM, не создаёт запись регистрации и не сообщает серверу, что в поле пароля находится значение TOTP. Интеграция на сервере и клиент должны договориться о взаимодействии, которое развёртывание действительно поддерживает: запрос, документированный объединённый формат учётных данных или процесс, специфичный для продукта.

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

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

Переподключения, токены и тест, который всё решает

Планируйте, что происходит после первого успешного входа. Ранее принятый код может истечь или быть отвергнут как повтор при следующей аутентификации. auth-nocache управляет хранением учётных данных и не устанавливает MFA, а reneg-sec 0 не является определением поддержки TOTP, как бы часто он ни встречался в темах форумов.

Некоторые развёртывания выдают токены аутентификации после первой проверки, чтобы переподключения не спрашивали снова. Это проектное решение с собственным окном действия и собственной историей отзыва, а не значение по умолчанию, которое вы наследуете.

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