UDP-VPN haltas dum senaktiveco: la fajroŝirmilo forgesis vian fluon

La VPN konektiĝas, funkcias dum iom da tempo kaj poste ĉesas pasigi trafikon dum la kliento ankoraŭ montras sesion. Rekonekto riparas ĝin, kio igas ĝin aspekti kiel klienta cimo. Kutime temas pri fajroŝirmilo aŭ NAT-aparato, kiu forigis senaktivan UDP-mapadon kaj tute ne scias, ke la tunelo ankoraŭ ekzistas.

La simptomo estas sufiĉe konsekvenca por diagnozi: ĝi aperas post senaktiveco, ne sub ŝarĝo.

Kiel aspektas halto pro senaktiveco

Mezuru ĝin anstataŭ priskribi ĝin. Notu, kiom longe la tunelo restas senaktiva antaŭ ol trafiko haltas, ĉu nova elira pako revivigas ĝin kaj ĉu la klienta interfaco ankoraŭ tenas sian adreson. Se nova peto de la kliento funkcias sed respondo al ekzistanta fluo ne, la mapado estas la suspektato. Se nenio funkcias ĝis vi rekonektas, ankaŭ la sesistato de la kliento perdiĝis.

Ambaŭ rilatas al senaktiveco, kaj ili bezonas malsamajn riparojn.

Skribu la tempojn antaŭ ol vi ŝanĝos ion ajn. Raporto, ke ĝi haltas post proksimume dek senaktivaj minutoj, estas testebla, dum raporto, ke ĝi falas hazarde, ne estas. Tiu diferenco decidas, ĉu vi postkuras tempigilon aŭ ŝanĝon de enkursigado.

Trovu la aparaton, kiu forgesis

Pluraj aparatoj povas teni staton por la sama fluo: la loka enkursigilo, supra tradukilo, nuba limo kaj la fajroŝirmilo de la gastiganto. Ĉiu havas sian propran tempigilon, kaj la plej mallonga venkas. Kvinminuta interrompo kutime signifas, ke unu aparato estas agordita multe sub la aliaj.

Ne supozu, ke dokumentita defaŭlto estas la tempolimo sur via vojo. Ĝi estas la defaŭlto de unu aparato.

• Hejma enkursigilo: ofte minutoj, foje multe malpli.
• Nuba NAT aŭ ŝarĝbalancilo: serĉu la dokumentitan senaktivan tempolimon specife por UDP.
• Fajroŝirmilo de la gastiganto: la spuraj tempigiloj de netfilter validas por ĉiu fluo.

Kontrolu la tempigilojn sur la reala vojo

En Linux la spuraj tempigiloj de netfilter estas videblaj kaj alĝustigeblaj: sysctl net.netfilter.nf_conntrack_udp_timeout kaj net.netfilter.nf_conntrack_udp_timeout_stream. La dua validas post kiam trafiko estis vidita en ambaŭ direktoj, kaj tial establita tunelo povas postvivi nudan sondan paketon.

RFC 4787 priskribas la konduton de UDP NAT kaj la rekomenditajn minimumojn. Ĝi estas la referenco citenda, kiam la defaŭlto de vendisto aspektas nekutime mallonga.

Keepalive kaj rekonekto estas malsamaj iloj

Keepalive tenas mapadon viva; rekonekto rekonstruas mortan sesion. Ili solvas malsamajn fiaskojn kaj ne estas interŝanĝeblaj rapidagordoj. La opcio PersistentKeepalive de WireGuard sendas pakon je fiksa intervalo por teni la NAT-ligon malfermita. La opcio keepalive de OpenVPN faras la saman laboron laŭ sia propra maniero. Neniu helpas, se la aparato meze jam forgesis la fluon kaj faligas ambaŭ direktojn.

Tre oftaj sondoj aldonas laboron sen ripari la malĝustan limon.

Kontrolu per nova peto, ne per paĝa reŝargo

Post ŝanĝi tempigilon aŭ aldoni keepalive, ripetu la senaktivan scenaron precize kiel antaŭe. Poste faru vere novan peton el la kovrita aplikaĵo. Retumila langeto jam ŝargita povas bildigi el kaŝmemoro kaj diras al vi nenion.

Se la halto daŭras, moviĝu unu salton eksteren kaj kontrolu la statan tabelon de tiu aparato.