Куда попадает код статического вызова при входе в OpenVPN

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

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

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

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

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

Что сервер должен поддерживать заранее

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

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

Здесь же нужно откалибровать ожидания. Второе приглашение — это механизм ввода, а не доказательство того, что применяется второй фактор, потому что применение происходит на стороне сервера и проявляется только при проверке неверного кода.

Кодированное поле, которое отправляет интерфейс управления

Когда интерфейс управляет соединением через интерфейс управления, пароль и ответ на вызов упаковываются в одно значение перед отправкой. Справочник по интерфейсу управления описывает формат: префикс, затем пароль и ответ как отдельные компоненты Base64.

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

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

Статическое против динамического: разное время

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

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

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

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

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

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