Почему VPN при переподключении снова запрашивает учётные данные
Сохранённый пароль и многоразовый токен истекают по разным расписаниям. Прочитайте, какой материал запросило переподключение, прежде чем что-то менять на клиенте.
Туннель, работавший часами, запрашивает пароль в тот момент, когда ноутбук просыпается, и в конфигурации ничего не изменилось. Изменилось состояние учётных данных, которые переподключение пыталось использовать повторно. Этим управляют три вида материала, и только один из них переживает произвольный перерыв.
Прочитайте, какой из них запросил клиент, потому что все три истекают по разным часам и отказывают с разными сообщениями.
Три вида многоразового материала
Кэшированный пароль — это секрет, который хранит клиент, и он остаётся действительным, пока учётная запись его не сменит. Токен сеанса выдаёт сервер после успешного входа, у него собственный срок жизни, и его можно отозвать в любой момент. Билет сеанса TLS или ассоциация безопасности IKE — это состояние протокола, дешёвое для возобновления и полностью независимое от вашего пароля. Каждый выдаётся отдельным компонентом, и каждый истекает на своих условиях.
Первый переживает перезагрузку, второй обычно переживает сон, а третий может вообще не пережить смену сети. Их путаница даёт неверное решение, например сброс пароля, который никогда не отклонялся.
Сам запрос — это диагностика. Окно браузера или код второго фактора означают, что сервер потребовал интерактивную аутентификацию, тогда как тихий отказ без запроса означает, что клиент так и не дошёл до момента, когда спрашивают.
| Material | Typical lifetime | What invalidates it |
|---|---|---|
| Cached password | Until changed | Account or password policy change |
| Session token | Minutes to hours | Expiry, revocation, reauthentication policy |
| Tunnel SA or TLS ticket | Configured rekey interval | Rekey, network change, peer restart |
Обновление ключей — не повторная аутентификация
Обновление ключей заменяет ключи, сохраняя аутентифицированную личность, поэтому на здоровом туннеле оно время от времени происходит тихо. Повторная аутентификация заново проводит саму проверку личности, и именно это событие требует вашего участия. IKEv2 явно разделяет эти две вещи, и партнёр может требовать полной повторной аутентификации через заданный интервал независимо от того, сколько обновлений ключей произошло между ними. Снаружи оба события выглядят одинаково, пока не прочитаешь, какое из них называет журнал.
OpenVPN ведёт себя так же в своей терминологии: интервал повторных переговоров обновляет канал данных, а токен аутентификации можно вернуть клиенту, чтобы избежать полного входа при следующем подключении. У этого токена есть срок, и сервер решает, принимать ли его снова.
Поэтому переподключение через восемь часов может не удаться там, где переподключение через восемь минут удалось, без каких-либо изменений конфигурации с обеих сторон. Это всё объяснение запроса, который появляется только после обеда.
Когда клиент не может завершить новую проверку
Политика, требующая шага в браузере, не сработает на клиенте, у которого нет способа его показать. Серверы без графического интерфейса, скрипты запуска и старые профили, созданные для аутентификации только по паролю, все упираются в эту стену, и сбой часто выглядит как общий тайм-аут, а не как ошибка аутентификации.
Переходы между устройствами и сетями тоже могут попасть в окно оценки политики, поэтому переход с Wi-Fi на точку доступа совпадает с проверкой, которая произошла бы в любом случае. Это совпадение делает сеть виноватой, когда причина — таймер.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
Первая строка показывает события повторных переговоров и аутентификации в собственном журнале клиента, а вторая показывает ассоциации безопасности, которые партнёр strongSwan держит сейчас. Сравните отметки времени с моментом появления запроса; совпадение подтверждает таймер, а не сеть.
Что сообщать и что не отключать
Если ручной вход удаётся, а автоматическое повторное использование стабильно не удаётся, скажите это оператору именно так. Это называет компонент: путь повторного использования, а не учётные данные. Укажите время сбоя, используемую учётную запись и тип запроса, который вы видели.
Не отключайте второй фактор, не пропускайте проверку сертификата и не вставляйте учётные данные в скрипт, чтобы переподключение проходило тихо. Каждое из этого убирает проверку, для которой существует политика, и каждое превращает запрос входа в инцидент.
Вместо этого попросите поддерживаемый сценарий: клиент, способный пройти вызов, срок жизни токена, соответствующий рабочему дню, или утверждённый неинтерактивный профиль для машины, которая не может спросить. Всё это решения конфигурации, которые кто-то может одобрить, а обходной путь — нет.