Запрос TOTP в OpenConnect отсутствует в NetworkManager: четыре проверки

Шлюз принимает пароль, запрашивает код, а диалог не предлагает для него ни одного поля. Ничего не было введено неправильно: плагин NetworkManager завершил обмен секретом, не запросив шестизначное значение. Пройдите четыре проверки ниже по порядку, потому что только одна из них меняет клиент. Остальная часть списка исключает шлюз, учётную запись и сборку плагина.

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

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

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

Запишите точную последовательность запросов, которую ожидает шлюз: имя пользователя, пароль, затем код, или имя пользователя, код, затем пароль. Некоторые шлюзы меняют порядок раундов, и клиент, знающий только первый порядок, застрянет на втором.

Вторая проверка: используйте клиент, которому принадлежит вызов

Сам OpenConnect реализует весь диалог, включая раунд вызова. Прямой запуск — самый предсказуемый способ убедиться, что учётная запись и шлюз работают:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

Клиент спрашивает в том порядке, в котором спрашивает шлюз. User agent важен, потому что некоторые шлюзы подстраивают поток входа под известный клиент, а общая строка может дать более короткий поток, который никогда не запрашивает код. Запустите его один раз на переднем плане, прежде чем настраивать любую фоновую службу.

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

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

Третья проверка: посмотрите, предлагает ли ваш плагин режим TOTP

Некоторые сборки NetworkManager OpenConnect предлагают режим токена и поле user agent на вкладке Identity подключения. Установите user agent в значение, которое ожидает шлюз, выберите ручной ввод TOTP и сохраните подключение.

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

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

Четвёртая проверка: относитесь к сгенерированному коду как к компромиссу

Скрипт может вызвать oathtool для текущего кода и передать имя пользователя, пароль и код в nmcli connection up --ask. Последовательность работает, но общий секрет в итоге хранится там, где его может прочитать любой, кто может открыть скрипт, и этот читатель может создавать коды вечно. Это постоянное расширение поверхности учётных данных, а не исправление клиента.

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

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

Убедитесь, что шлюз и учётная запись те же

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

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

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