UDP VPN stane kada miruje: firewall je zaboravio vaš tok

VPN se poveže, radi neko vrijeme, a zatim prestane propuštati saobraćaj dok klijent još prikazuje sesiju. Ponovno povezivanje to popravi, zbog čega izgleda kao greška u klijentu. Obično je riječ o firewallu ili NAT uređaju koji je ispustio neaktivno UDP mapiranje i nema pojma da tunel još postoji.

Simptom je dovoljno dosljedan za dijagnozu: pojavljuje se nakon neaktivnosti, a ne pod opterećenjem.

Kako izgleda zastoj zbog mirovanja

Izmjerite ga umjesto da ga opisujete. Zabilježite koliko tunel miruje prije nego saobraćaj stane, oživljava li ga novi odlazni paket i zadržava li klijentski interfejs svoju adresu. Ako novi zahtjev s klijenta radi, a odgovor na postojeći tok ne, mapiranje je osumnjičeno. Ako ništa ne radi dok se ponovo ne povežete, izgubljeno je i stanje sesije na klijentu.

Oba su vezana za mirovanje i traže različite popravke.

Zapišite vremena prije nego što bilo šta promijenite. Izvještaj da staje nakon otprilike deset minuta mirovanja može se provjeriti, dok izvještaj da pada nasumično ne može. Ta razlika odlučuje da li lovite tajmer ili promjenu rutiranja.

Pronađite uređaj koji je zaboravio

Nekoliko uređaja može držati stanje za isti tok: lokalni ruter, uzvodni prevodilac, granica oblaka i firewall na hostu. Svaki ima svoj tajmer i najkraći pobjeđuje. Petominutni prekid obično znači da je jedan uređaj konfigurisan znatno ispod ostalih.

Ne pretpostavljajte da je dokumentovana zadana vrijednost tajmaut na vašoj putanji. To je zadana vrijednost jednog uređaja.

• Kućni ruter: često minute, ponekad znatno manje.
• Cloud NAT ili balanser opterećenja: potražite dokumentovani tajmaut mirovanja posebno za UDP.
• Firewall na hostu: netfilter tajmeri praćenja važe po toku.

Provjerite tajmere na stvarnoj putanji

Na Linuxu su netfilter tajmeri praćenja vidljivi i podesivi: sysctl net.netfilter.nf_conntrack_udp_timeout i net.netfilter.nf_conntrack_udp_timeout_stream. Drugi važi kada je saobraćaj viđen u oba smjera, zato uspostavljeni tunel može nadživjeti običnu provjeru.

RFC 4787 opisuje ponašanje UDP NAT-a i preporučene minimume. To je referenca koju treba citirati kada zadana vrijednost dobavljača izgleda neuobičajeno kratka.

Keepalive i ponovno povezivanje su različiti alati

Keepalive održava mapiranje živim; ponovno povezivanje gradi mrtvu sesiju iznova. Oni rješavaju različite kvarove i nisu zamjenjive postavke brzine. WireGuardov PersistentKeepalive šalje paket u fiksnom intervalu da drži NAT vezu otvorenom. OpenVPN-ova keepalive opcija radi isti posao na svoj način. Nijedno ne pomaže ako je uređaj u sredini već zaboravio tok i odbacuje oba smjera.

Izuzetno česte provjere dodaju posao bez popravke pogrešne granice.

Provjerite novim zahtjevom, a ne osvježavanjem stranice

Nakon promjene tajmera ili dodavanja keepalivea ponovite scenarij mirovanja tačno kao prije. Zatim uputite zaista novi zahtjev iz pokrivene aplikacije. Kartica pregledača koja je već bila učitana može se prikazati iz keša i neće vam reći ništa.

Ako zastoj potraje, pomaknite se jedan hop prema van i provjerite tabelu stanja tog uređaja.