VPN переподключился, но сеанс приложения всё равно срывается

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

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

Что переживает переподключение, а что нет

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

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

Удалённая сторона тоже вас забыла

Дальний конец держит собственное состояние: сеанс TLS, блок управления TCP и, возможно, запись отображения, связывающую ваш адрес и порт с потоком. Устройство трансляции на пути может дать этому отображению истечь за время разрыва, даже если туннель восстанавливается быстро. Как только отображение исчезает, пакеты приходят для потока, который сервер уже не узнаёт, и ответом может быть сброс, которого клиент никогда не показывает. Приложения сообщают об этом как о зависании, а не об ошибке, потому что они всё ещё ждут сокет, который никогда не ответит.

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

Новый запрос — это тест, который их разделяет

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

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

Подтвердите новым соединением, а не старым

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

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

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

Запишите время прерывания, время переподключения и разницу между старым и новым запросом. Эта запись превращает смутную жалобу в отчёт, с которым кто-то может работать.