OpenVPN позже сбрасывает сеанс OTP: что нужно повторной аутентификации

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

Решение — это выбор того, что должно предъявить второе рукопожатие, а не более длинный таймер повторных попыток.

Пройдите обмен с точки зрения клиента

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

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

auth-gen-token меняет того, кто отвечает на второй вопрос

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

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

Решите, что происходит со статусом учётной записи

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

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

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

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

Удаление учётной записи проверяйте последним. Этот случай показывает, исполняется ли написанная вами политика или она только задокументирована.

Не исправляйте это отключением продления

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

Более длинный таймер повторных попыток не делает израсходованный код снова действительным. Он лишь отодвигает разрыв и усложняет чтение журнала.