VPN через UDP замирает в простое: межсетевой экран забыл ваш поток

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

Симптом достаточно устойчив для диагностики: он появляется после простоя, а не под нагрузкой.

Как выглядит остановка из-за простоя

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

Оба случая связаны с простоем, и им нужны разные исправления.

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

Найдите устройство, которое забыло

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

Не считайте, что документированное значение по умолчанию — это тайм-аут на вашем пути. Это значение по умолчанию одного устройства.

• Домашний маршрутизатор: часто минуты, иногда гораздо меньше.
• Облачный NAT или балансировщик нагрузки: ищите документированный тайм-аут простоя именно для UDP.
• Межсетевой экран хоста: таймеры отслеживания netfilter действуют для каждого потока.

Проверьте таймеры на реальном пути

В Linux таймеры отслеживания netfilter видны и настраиваются: sysctl net.netfilter.nf_conntrack_udp_timeout и net.netfilter.nf_conntrack_udp_timeout_stream. Второй действует, когда трафик уже виден в обоих направлениях, поэтому установленный туннель может пережить простую проверку.

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

Keepalive и переподключение — разные инструменты

Keepalive поддерживает сопоставление живым; переподключение заново строит мёртвый сеанс. Они решают разные сбои и не являются взаимозаменяемыми настройками скорости. Параметр PersistentKeepalive в WireGuard отправляет пакет с фиксированным интервалом, чтобы удерживать привязку NAT открытой. Параметр keepalive в OpenVPN делает ту же работу по-своему. Ни один не поможет, если устройство посередине уже забыло поток и сбрасывает оба направления.

Слишком частые проверки добавляют работы, не исправляя неверную границу.

Проверяйте новым запросом, а не перезагрузкой страницы

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

Если остановка сохраняется, сдвиньтесь на один шаг наружу и проверьте таблицу состояний этого устройства.