UDP VPN se při nečinnosti zasekne: firewall zapomněl váš tok

VPN se připojí, chvíli funguje a pak přestane propouštět provoz, zatímco klient stále ukazuje relaci. Opětovné připojení to spraví, a proto to vypadá jako chyba klienta. Obvykle jde o firewall nebo zařízení NAT, které zahodilo neaktivní UDP mapování a nemá ponětí, že tunel ještě existuje.

Příznak je dostatečně konzistentní na diagnostiku: objevuje se po nečinnosti, ne pod zátěží.

Jak vypadá zaseknutí při nečinnosti

Změřte to, místo abyste to popisovali. Zapište, jak dlouho tunel nečinně stojí, než provoz ustane, zda ho nový odchozí paket oživí a zda si klientské rozhraní stále drží svou adresu. Pokud nový požadavek z klienta funguje, ale odpověď na existující tok ne, podezřelé je mapování. Pokud nic nefunguje, dokud se znovu nepřipojíte, je ztracen i stav relace v klientovi.

Oba případy souvisejí s nečinností a potřebují různá řešení.

Zapište si časy, než cokoli změníte. Hlášení, že se to zastaví po zhruba deseti minutách nečinnosti, je ověřitelné, kdežto hlášení, že to padá náhodně, ověřitelné není. Tento rozdíl rozhoduje, zda honíte časovač, nebo změnu směrování.

Najděte zařízení, které zapomnělo

Stav pro stejný tok může držet několik zařízení: místní router, překladač výše v cestě, hranice cloudu a firewall hostitele. Každé má svůj časovač a vyhrává ten nejkratší. Pětiminutový výpadek obvykle znamená, že jedno zařízení je nastaveno výrazně níž než ostatní.

Nepředpokládejte, že dokumentovaná výchozí hodnota je časový limit na vaší cestě. Je to výchozí hodnota jednoho zařízení.

• Domácí router: často minuty, někdy mnohem méně.
• Cloudový NAT nebo vyrovnávací paměť zátěže: vyhledejte dokumentovaný časový limit nečinnosti konkrétně pro UDP.
• Firewall hostitele: časovače sledování netfilter platí pro každý tok.

Zkontrolujte časovače na skutečné cestě

V Linuxu jsou časovače sledování netfilter viditelné a nastavitelné: sysctl net.netfilter.nf_conntrack_udp_timeout a net.netfilter.nf_conntrack_udp_timeout_stream. Druhý platí, jakmile byl provoz viděn v obou směrech, a proto zavedený tunel může přežít obyčejnou sondu.

RFC 4787 popisuje chování UDP NAT a doporučená minima. Je to reference, kterou citujte, když výchozí hodnota dodavatele vypadá neobvykle krátká.

Keepalive a opětovné připojení jsou různé nástroje

Keepalive udržuje mapování živé; opětovné připojení staví mrtvou relaci znovu. Řeší různé poruchy a nejsou to zaměnitelná nastavení rychlosti. Volba WireGuardu PersistentKeepalive posílá paket v pevném intervalu, aby udržela NAT vazbu otevřenou. Volba OpenVPN keepalive dělá stejnou práci po svém. Ani jedna nepomůže, pokud zařízení uprostřed už tok zapomnělo a zahazuje oba směry.

Velmi časté sondy přidávají práci, aniž by opravily špatnou hranici.

Ověřujte novým požadavkem, ne obnovením stránky

Po změně časovače nebo přidání keepalive zopakujte scénář nečinnosti přesně jako předtím. Potom z pokryté aplikace pošlete skutečně nový požadavek. Panel prohlížeče, který už byl načtený, se může vykreslit z mezipaměti a nic vám neřekne.

Pokud zaseknutí trvá, posuňte se o jeden skok ven a zkontrolujte tabulku stavů daného zařízení.