UDP-VPN stannar vid inaktivitet: brandväggen glömde ditt flöde

VPN:et ansluter, fungerar ett tag och slutar sedan föra trafik medan klienten fortfarande visar en session. Att ansluta igen löser det, vilket får det att se ut som en bugg i klienten. Oftast är det en brandvägg eller NAT-enhet som släppte en inaktiv UDP-mappning och inte har en aning om att tunneln finns kvar.

Symtomet är tillräckligt konsekvent för att diagnosticeras: det dyker upp efter inaktivitet, inte under last.

Hur ett inaktivitetsstopp ser ut

Mät det i stället för att beskriva det. Notera hur länge tunneln ligger stilla innan trafiken stannar, om ett nytt utgående paket väcker den till liv och om klientens gränssnitt fortfarande håller kvar sin adress. Om en ny begäran från klienten fungerar men ett svar till ett befintligt flöde inte gör det, är mappningen den misstänkta. Om inget fungerar förrän du ansluter igen är klientens sessionsläge också borta.

Båda hänger ihop med inaktivitet, och de kräver olika åtgärder.

Skriv ner tiderna innan du ändrar något. En rapport om att det stannar efter ungefär tio inaktiva minuter går att testa, medan en rapport om att det faller slumpmässigt inte gör det. Den skillnaden avgör om du jagar en timer eller en ändring i routingen.

Hitta enheten som glömde

Flera enheter kan hålla tillstånd för samma flöde: den lokala routern, en översättare längre upp, en molngräns och värdens brandvägg. Var och en har sin egen timer, och den kortaste vinner. Ett avbrott på fem minuter betyder oftast att en enhet är konfigurerad långt under de andra.

Utgå inte från att ett dokumenterat standardvärde är tidsgränsen på din väg. Det är en enda enhets standardvärde.

• Hemmarouter: ofta minuter, ibland mycket mindre.
• Moln-NAT eller lastbalanserare: slå upp den dokumenterade inaktivitetsgränsen specifikt för UDP.
• Värdens brandvägg: netfilters spårningstimers gäller per flöde.

Kontrollera timers på den faktiska vägen

På Linux är netfilters spårningstimers synliga och justerbara: sysctl net.netfilter.nf_conntrack_udp_timeout och net.netfilter.nf_conntrack_udp_timeout_stream. Den andra gäller när trafik har setts i båda riktningarna, och därför kan en etablerad tunnel överleva en naken sond.

RFC 4787 beskriver UDP-NAT-beteende och rekommenderade minimum. Det är referensen att citera när en leverantörsstandard ser ovanligt kort ut.

Keepalive och återanslutning är olika verktyg

En keepalive håller en mappning vid liv; en återanslutning bygger upp en död session igen. De löser olika fel och är inte utbytbara hastighetsinställningar. WireGuards PersistentKeepalive skickar ett paket med fast intervall för att hålla NAT-bindningen öppen. OpenVPN:s keepalive alternativ gör samma jobb på sitt eget sätt. Ingen av dem hjälper om enheten i mitten redan har glömt flödet och släpper båda riktningarna.

Mycket täta prober lägger till arbete utan att fixa den felaktiga gränsen.

Verifiera med en ny begäran, inte med en omladdning av sidan

När du har ändrat en timer eller lagt till en keepalive, upprepa inaktivitetsscenariot exakt som tidigare. Gör sedan en verkligen ny begäran från det täckta programmet. En flik i webbläsaren som redan var laddad kan renderas från cachen och säger dig ingenting.

Om stoppet kvarstår, flytta dig ett hopp utåt och kontrollera den enhetens tillståndstabell.