Почему VPN восстанавливается дольше, чем длится сбой

Wi-Fi вернулся тридцать секунд назад, а VPN всё ещё не работает, поэтому клиент выглядит сломанным. Часто он просто следует собственному графику повторов, а этот график не знает, что сеть только что вернулась. Этот разрыв и есть вся история: время восстановления — это сбой плюс любое ожидание, на которое клиент уже согласился. Снизить каждый таймер — один ответ, а понять, какой таймер важен, — другой.

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

Три ожидания, которые выглядят как одно

Определение конечной точки, согласование IKE или TLS, повторная передача пакетов и запуск новой попытки — отдельные события с отдельными таймерами. strongSwan документирует задержку повторной передачи для IKE, а OpenVPN имеет собственные средства управления повторами с другой семантикой. Копирование числа из одного в другое предполагает, что механизмы совпадают, но они не совпадают. Прочитайте последовательность в журнале, прежде чем решать, на какой интервал вы смотрите.

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

Какой этап на самом деле медленный?

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

Классифицируйте сбой, прежде чем трогать число.

Когда снижение таймера помогает, а когда нет

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

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

Проверьте готовность, прежде чем винить клиент

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

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

Что записывать

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

Эта запись превращает следующее обновление программного обеспечения в сравнение, а не в эксперимент.