UDP-VPN stopper ved inaktivitet: brannmuren glemte flyten din

VPN-en kobler til, virker en stund og slutter deretter å føre trafikk mens klienten fortsatt viser en økt. Å koble til på nytt fikser det, og derfor ser det ut som en feil i klienten. Vanligvis er det en brannmur eller NAT-enhet som har droppet en inaktiv UDP-mapping og ikke aner at tunnelen fortsatt finnes.

Symptomet er konsistent nok til å diagnostiseres: det dukker opp etter inaktivitet, ikke under last.

Slik ser et inaktivitetsstopp ut

Mål det i stedet for å beskrive det. Noter hvor lenge tunnelen ligger stille før trafikken stopper, om en ny utgående pakke vekker den til live, og om klientgrensesnittet fortsatt holder på adressen sin. Hvis en fersk forespørsel fra klienten virker, men et svar til en eksisterende flyt ikke gjør det, er mappingen den mistenkte. Hvis ingenting virker før du kobler til på nytt, er øktstilstanden i klienten også borte.

Begge er knyttet til inaktivitet, og de trenger ulike rettelser.

Skriv ned tidene før du endrer noe. En rapport om at det stopper etter rundt ti inaktive minutter er testbar, mens en rapport om at det faller tilfeldig ikke er det. Den forskjellen avgjør om du jager en timer eller en endring i rutingen.

Finn enheten som glemte

Flere enheter kan holde tilstand for den samme flyten: den lokale ruteren, en oversetter lenger oppe, en skygrense og vertens brannmur. Hver har sin egen timer, og den korteste vinner. Et avbrudd på fem minutter betyr vanligvis at én enhet er konfigurert langt under de andre.

Ikke anta at en dokumentert standardverdi er tidsavbruddet på din vei. Det er én enhets standardverdi.

• Hjemmeruter: ofte minutter, noen ganger langt mindre.
• Sky-NAT eller lastbalanserer: slå opp det dokumenterte inaktivitetsavbruddet spesielt for UDP.
• Vertens brannmur: netfilter-sporingstimere gjelder per flyt.

Sjekk timere på den faktiske veien

På Linux er netfilter-sporingstimerne synlige og justerbare: sysctl net.netfilter.nf_conntrack_udp_timeout og net.netfilter.nf_conntrack_udp_timeout_stream. Den andre gjelder når trafikk er sett i begge retninger, og derfor kan en etablert tunnel overleve en naken probe.

RFC 4787 beskriver UDP-NAT-atferd og anbefalte minimumsverdier. Det er referansen du bør sitere når en leverandørstandard ser uvanlig kort ut.

Keepalive og gjentilkobling er forskjellige verktøy

En keepalive holder en mapping i live; en gjentilkobling bygger en død økt på nytt. De løser forskjellige feil og er ikke utskiftbare hastighetsinnstillinger. WireGuards PersistentKeepalive sender en pakke med fast intervall for å holde NAT-bindingen åpen. OpenVPNs keepalive alternativ gjør samme jobb på sin egen måte. Ingen av dem hjelper hvis enheten i midten allerede har glemt flyten og dropper begge retninger.

Svært hyppige prober legger til arbeid uten å rette den feil grensen.

Verifiser med en ny forespørsel, ikke en sideinnlasting

Etter at du har endret en timer eller lagt til en keepalive, gjenta inaktivitetsscenarioet nøyaktig som før. Lag deretter en virkelig ny forespørsel fra programmet som dekkes. En nettleserfane som allerede var lastet, kan rendres fra hurtiglageret og forteller deg ingenting.

Hvis stoppet vedvarer, flytt deg ett hopp utover og sjekk tilstandstabellen til den enheten.