UDP-VPN stoppar ved inaktivitet: brannmuren gløymde flyten din

VPN-en koplar til, verkar ei stund og sluttar deretter å føre trafikk medan klienten framleis viser ei økt. Å kopie til på nytt løyser det, og difor ser det ut som ein feil i klienten. Vanlegvis er det ein brannmur eller ei NAT-eining som har droppa ei inaktiv UDP-mapping og ikkje anar at tunnelen framleis finst.

Symptomet er konsistent nok til å kunne diagnostiserast: det dukkar opp etter inaktivitet, ikkje under last.

Slik ser eit inaktivitetsstopp ut

Mål det i staden for å skildre det. Noter kor lenge tunnelen ligg stille før trafikken stoppar, om ein ny utgåande pakke vekkjer han til live, og om klientgrensesnittet framleis held på adressa si. Viss ein fersk førespurnad frå klienten verkar, men eit svar til ein eksisterande flyt ikkje gjer det, er mappinga den mistenkte. Viss ingenting verkar før du koplar til på nytt, er økttilstanden i klienten òg borte.

Båe er knytte til inaktivitet, og dei treng ulike rettingar.

Skriv ned tidene før du endrar noko. Ein rapport om at det stoppar etter rundt ti inaktive minutt er testbar, medan ein rapport om at det fell tilfeldig ikkje er det. Den skilnaden avgjer om du jagar ein timer eller ei endring i rutinga.

Finn eininga som gløymde

Fleire einingar kan halde tilstand for den same flyten: den lokale rutaren, ein omsetjar lenger oppe, ei skygrense og brannmuren til verten. Kvar har sin eigen timer, og den kortaste vinn. Eit avbrot på fem minutt tyder vanlegvis at éi eining er konfigurert langt under dei andre.

Ikkje gå ut frå at ein dokumentert standardverdi er tidsavbrotet på vegen din. Det er standardverdien til éi eining.

• Heimerutar: ofte minutt, nokre gonger langt mindre.
• Sky-NAT eller lastbalansar: slå opp det dokumenterte inaktivitetsavbrotet spesielt for UDP.
• Brannmur på verten: netfilter-sporingstimarar gjeld per flyt.

Sjekk timerane på den faktiske vegen

På Linux er netfilter-sporingstimarane synlege og justerbare: sysctl net.netfilter.nf_conntrack_udp_timeout og net.netfilter.nf_conntrack_udp_timeout_stream. Den andre gjeld når trafikk er sett i båe retningar, og difor kan ein etablert tunnel overleve ein naken probe.

RFC 4787 skildrar UDP-NAT-åtferd og tilrådde minimumsverdiar. Det er referansen du bør sitere når ein leverandørstandard ser uvanleg kort ut.

Keepalive og ny tilkopling er ulike verkty

Ein keepalive held ei mapping i live; ei ny tilkopling byggjer ei død økt på nytt. Dei løyser ulike feil og er ikkje utskiftbare hastigheitsinnstillingar. WireGuards PersistentKeepalive sender ein pakke med fast intervall for å halde NAT-bindinga open. OpenVPNs keepalive alternativ gjer same jobben på sin eigen måte. Ingen av dei hjelper viss eininga i midten alt har gløymt flyten og droppar båe retningar.

Svært hyppige probar legg til arbeid utan å rette den feile grensa.

Stadfest med ein ny førespurnad, ikkje med ei sideinnlasting

Etter at du har endra ein timer eller lagt til ein keepalive, gjer inaktivitetsscenarioet om att nøyaktig som før. Lag deretter ein verkeleg ny førespurnad frå programmet som er dekt. Ei nettlesarfane som alt var lasta, kan renderast frå hurtiglageret og fortel deg ingenting.

Viss stoppet held fram, flytt deg eitt hopp utover og sjekk tilstandstabellen til den eininga.