Таймер сеанса VPN и токен аутентификации истекают по отдельности

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

Против одного туннеля идут трое часов, и только одни из них — сам туннель.

Трое разных часов на одном туннеле

Часы сеанса принадлежат шлюзу: максимальная длительность соединения, тайм-аут простоя или оба, и они завершают туннель, когда достигается любой из них. Часы токена принадлежат системе аутентификации, и они решают, как долго учетные данные можно предъявлять снова без участия человека. Часы пути принадлежат любому NAT или межсетевому экрану между клиентом и шлюзом, и они дают истечь сопоставлениям потоков, которые считают завершенными. Все трое дают разрыв соединения, и ни одни не дают ту же строку журнала.

Только первые — понятие VPN. Остальные двое заимствованы из идентичности и сетей, и их регулярно путают с ним.

Как токен на самом деле используется повторно

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

Интервал повторного согласования — отдельный параметр. Его изменение сдвигает момент предъявления токена, а не срок его жизни.

Как выглядит каждый из истечений со стороны клиента

Тайм-аут сеанса обычно приходит как чистое отключение с причиной на стороне сервера, часто после предсказуемой длительности и без ошибки аутентификации. Тайм-аут простоя выглядит как тишина: туннель перестает нести трафик, затем механизм поддержания связи сдается. Истечение токена приходит как AUTH_FAILED посреди сеанса, который работал секунду назад.

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

Почему сохраненный пароль не помогает

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

Устойчивые исправления — это правильный срок жизни на правильном объекте, либо клиентский поток, способный выполнить требуемый запрос без человека.

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

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

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