UDP VPN спира при бездействие: защитната стена забрави потока ви

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 поддържа съответствието живо; повторното свързване изгражда мъртва сесия наново. Те решават различни откази и не са взаимозаменяеми настройки за скорост. При WireGuard PersistentKeepalive изпраща пакет на фиксиран интервал, за да държи NAT връзката отворена. При OpenVPN keepalive прави същата работа по свой начин. Нито едно не помага, ако устройството по средата вече е забравило потока и изхвърля двете посоки.

Изключително честите проби добавят работа, без да поправят грешната граница.

Проверете с ново искане, а не с презареждане на страница

След като промените таймер или добавите keepalive, повторете сценария на бездействие точно както преди. След това направете наистина ново искане от покритото приложение. Раздел на браузъра, който вече е бил зареден, може да се изобрази от кеша и да не ви каже нищо.

Ако спирането продължава, преместете се с един хоп навън и проверете таблицата на състоянията на това устройство.