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-а поновите сценарио мировања тачно као пре. Затим упутите заиста нови захтев из покривене апликације. Картица прегледача која је већ била учитана може се приказати из кеша и неће вам рећи ништа.

Ако застој потраје, померите се један хоп ка споља и проверите табелу стања тог уређаја.