VPN-i përmes UDP ngec në papunësi: firewali harroi fluksin tënd

VPN-i lidhet, punon për një kohë dhe pastaj ndalon kalimin e trafikut ndërsa klienti vazhdon të shfaqë një sesion. Rilidhja e rregullon, prandaj duket si një gabim i klientit. Zakonisht është një firewal ose pajisje NAT që hodhi një hartëzim UDP joaktiv dhe nuk e ka idenë se tuneli ekziston ende.

Simptoma është mjaftueshëm e qëndrueshme për diagnozë: shfaqet pas papunësisë, jo nën ngarkesë.

Si duket një ngecje nga papunësia

Matni atë në vend që ta përshkruani. Shënoni sa kohë qëndron tuneli joaktiv përpara se trafiku të ndalet, nëse një paketë e re dalëse e ringjall dhe nëse ndërfaqja e klientit e mban ende adresën e saj. Nëse një kërkesë e re nga klienti punon por një përgjigje për një fluks ekzistues jo, hartëzimi është i dyshuari. Nëse asgjë nuk punon derisa të rilidheni, edhe gjendja e sesionit të klientit është humbur.

Të dyja lidhen me papunësinë dhe kërkojnë rregullime të ndryshme.

Shënoni kohët përpara se të ndryshoni gjithçka. Një raport se ndalon pas rreth dhjetë minutash papunësi është i verifikueshëm, ndërsa një raport se bie rastësisht nuk është. Ky ndryshim vendos nëse ndiqni një kohëmatës apo një ndryshim rrugëtimi.

Gjeni pajisjen që harroi

Disa pajisje mund të mbajnë gjendje për të njëjtin fluks: ruteri lokal, një përkthyes më lart, një kufi cloud dhe firewali i strehuesit. Secili ka kohëmatësin e vet, dhe fiton më i shkurtri. Një ndërprerje pesë minutash zakonisht do të thotë se një pajisje është konfiguruar shumë më poshtë se të tjerat.

Mos supozoni se vlera e paracaktuar e dokumentuar është afati kohor në rrugën tuaj. Është vlera e paracaktuar e një pajisjeje të vetme.

• Ruter shtëpiak: shpesh minuta, ndonjëherë shumë më pak.
• NAT cloud ose balancues ngarkese: kërkoni afatin kohor të papunësisë të dokumentuar posaçërisht për UDP.
• Firewali i strehuesit: kohëmatësit e gjurmimit të netfilter zbatohen për çdo fluks.

Kontrolloni kohëmatësit në rrugën reale

Në Linux, kohëmatësit e gjurmimit të netfilter janë të dukshëm dhe të rregullueshëm: sysctl net.netfilter.nf_conntrack_udp_timeout dhe net.netfilter.nf_conntrack_udp_timeout_stream. I dyti zbatohet pasi trafiku është parë në të dy drejtimet, prandaj një tunel i vendosur mund t'i mbijetojë një sondë të thjeshtë.

RFC 4787 përcakton sjelljen e UDP NAT dhe minimumet e rekomanduara. Është referenca që duhet cituar kur vlera e paracaktuar e një furnizuesi duket jashtëzakonisht e shkurtër.

Keepalive dhe rilidhja janë mjete të ndryshme

Një keepalive mban gjallë një hartëzim; rilidhja rindërton një sesion të vdekur. Ato zgjidhin dështime të ndryshme dhe nuk janë cilësime shpejtësie të këmbyeshme. Opsioni PersistentKeepalive i WireGuard dërgon një paketë në interval fiks për të mbajtur të hapur lidhjen NAT. Opsioni keepalive i OpenVPN bën të njëjtën punë në mënyrën e vet. Asnjëra nuk ndihmon nëse pajisja në mes e ka harruar tashmë fluksin dhe po hedh të dy drejtimet.

Sondat shumë të shpeshta shtojnë punë pa rregulluar kufirin e gabuar.

Verifikoni me një kërkesë të re, jo me një ringarkim faqeje

Pasi të ndryshoni një kohëmatës ose të shtoni një keepalive, përsëritni skenarin e papunësisë saktësisht si më parë. Pastaj bëni një kërkesë vërtet të re nga aplikacioni i mbuluar. Një skedë shfletuesi e ngarkuar më parë mund të vizatohet nga cache dhe nuk ju thotë asgjë.

Nëse ngecja vazhdon, lëvizni një kërcim nga jashtë dhe kontrolloni tabelën e gjendjes së asaj pajisjeje.