UDP-VPN går i stå ved inaktivitet: firewalla glemte din flow

VPN'en opretter forbindelse, virker et stykke tid og holder derefter op med at føre trafik, mens klienten stadig viser en session. Genopkobling løser det, hvilket får det til at se ud som en fejl i klienten. Det er som regel en firewall eller NAT-enhed, der har droppet en inaktiv UDP-mapping og ikke aner, at tunnelen stadig findes.

Symptomet er konsistent nok til at diagnosticere: det viser sig efter inaktivitet, ikke under last.

Sådan ser en inaktivitetsstilstand ud

Mål den i stedet for at beskrive den. Noter, hvor længe tunnelen ligger stille, før trafikken stopper, om en ny udgående pakke genopliver den, og om klientens interface stadig holder sin adresse. Hvis en frisk anmodning fra klienten virker, men et svar til en eksisterende flow ikke gør, er mappingen den mistænkte. Hvis intet virker, før du genopkobler, er klientens sessionstilstand også væk.

Begge er relateret til inaktivitet, og de kræver forskellige løsninger.

Skriv tidspunkterne ned, før du ændrer noget. En rapport om, at det stopper efter cirka ti inaktive minutter, er testbar, mens en rapport om, at det falder tilfældigt, ikke er. Den forskel afgør, om du jager en timer eller en ændring i routing.

Find den enhed, der glemte

Flere enheder kan holde tilstand for den samme flow: den lokale router, en oversætter længere oppe, en cloud-grænse og værtens firewall. Hver har sin egen timer, og den korteste vinder. Et afbrud på fem minutter betyder som regel, at én enhed er konfigureret langt under de andre.

Antag ikke, at en dokumenteret standardværdi er timeoutet på din vej. Det er én enheds standard.

• Hjemmerouter: ofte minutter, nogle gange langt mindre.
• Cloud-NAT eller load balancer: slå det dokumenterede inaktivitets-timeout op specifikt for UDP.
• Værtens firewall: netfilter-sporingstimere gælder pr. flow.

Tjek timerne på den faktiske vej

På Linux er netfilter-sporingstimerne synlige og justerbare: sysctl net.netfilter.nf_conntrack_udp_timeout og net.netfilter.nf_conntrack_udp_timeout_stream. Den anden gælder, når trafik er set i begge retninger, og derfor kan en etableret tunnel overleve en nøgen probe.

RFC 4787 beskriver UDP-NAT-adfærd og anbefalede minimumsværdier. Det er referencen, du bør citere, når en leverandørs standard ser usædvanligt kort ud.

Keepalive og genopkobling er forskellige værktøjer

En keepalive holder en mapping i live; en genopkobling genopbygger en død session. De løser forskellige fejl og er ikke udskiftelige hastighedsindstillinger. WireGuards PersistentKeepalive sender en pakke med et fast interval for at holde NAT-bindingen åben. OpenVPNs keepalive indstilling gør det samme på sin egen måde. Ingen af dem hjælper, hvis enheden i midten allerede har glemt flowen og dropper begge retninger.

Ekstremt hyppige prober tilføjer arbejde uden at rette den forkerte grænse.

Verificér med en ny anmodning, ikke en sides genindlæsning

Når du har ændret en timer eller tilføjet en keepalive, gentag inaktivitetsscenariet præcis som før. Lav derefter en virkelig ny anmodning fra det dækkede program. En browservifte, der allerede var indlæst, kan vise sig fra cachen og fortæller dig intet.

Hvis stilstanden fortsætter, flyt dig et hop udad og tjek den enheds tilstandstabel.