VPN-ul prin UDP se blochează în inactivitate: firewall-ul a uitat fluxul tău

VPN-ul se conectează, funcționează o vreme și apoi nu mai lasă traficul să treacă, în timp ce clientul încă arată o sesiune. Reconectarea rezolvă, ceea ce îl face să pară o eroare a clientului. De obicei este un firewall sau un dispozitiv NAT care a aruncat o mapare UDP inactivă și nu are habar că tunelul încă există.

Simptomul este suficient de consecvent pentru diagnostic: apare după inactivitate, nu sub sarcină.

Cum arată un blocaj din inactivitate

Măsoară-l în loc să-l descrii. Notează cât timp stă tunelul inactiv înainte ca traficul să se oprească, dacă un pachet nou de ieșire îl readuce la viață și dacă interfața clientului își mai ține adresa. Dacă o cerere nouă de la client funcționează, dar un răspuns către un flux existent nu, maparea este suspectul. Dacă nimic nu funcționează până nu te reconectezi, și starea sesiunii clientului s-a pierdut.

Ambele au legătură cu inactivitatea și au nevoie de corecții diferite.

Notează timpii înainte să schimbi ceva. Un raport că se oprește după vreo zece minute de inactivitate este verificabil, în timp ce un raport că pică aleatoriu nu este. Această diferență decide dacă urmărești un temporizator sau o schimbare de rutare.

Găsește dispozitivul care a uitat

Mai multe dispozitive pot ține stare pentru același flux: routerul local, un traducător mai sus, o graniță de cloud și firewall-ul gazdei. Fiecare are propriul temporizator, iar cel mai scurt câștigă. O întrerupere de cinci minute înseamnă de obicei că un dispozitiv este configurat mult sub celelalte.

Nu presupune că valoarea implicită documentată este limita de timp pe calea ta. Este valoarea implicită a unui singur dispozitiv.

• Router de acasă: adesea minute, uneori mult mai puțin.
• NAT în cloud sau balansator de încărcare: caută limita de inactivitate documentată special pentru UDP.
• Firewall-ul gazdei: temporizoarele de urmărire netfilter se aplică pe flux.

Verifică temporizoarele pe calea reală

În Linux, temporizoarele de urmărire netfilter sunt vizibile și reglabile: sysctl net.netfilter.nf_conntrack_udp_timeout și net.netfilter.nf_conntrack_udp_timeout_stream. Al doilea se aplică după ce s-a văzut trafic în ambele direcții, motiv pentru care un tunel stabilit poate supraviețui unei simple sondări.

RFC 4787 descrie comportamentul UDP NAT și minimele recomandate. Este referința de citat când valoarea implicită a unui furnizor pare neobișnuit de scurtă.

Keepalive și reconectarea sunt instrumente diferite

Un keepalive ține o mapare în viață; o reconectare reconstruiește o sesiune moartă. Rezolvă defecțiuni diferite și nu sunt setări de viteză interschimbabile. Opțiunea PersistentKeepalive din WireGuard trimite un pachet la un interval fix pentru a ține legătura NAT deschisă. Opțiunea keepalive din OpenVPN face aceeași treabă în felul ei. Niciuna nu ajută dacă dispozitivul din mijloc a uitat deja fluxul și aruncă ambele direcții.

Sondările foarte frecvente adaugă muncă fără să repare granița greșită.

Verifică cu o cerere nouă, nu cu o reîncărcare de pagină

După ce schimbi un temporizator sau adaugi un keepalive, repetă scenariul de inactivitate exact ca înainte. Apoi fă o cerere cu adevărat nouă din aplicația acoperită. Un tab de browser deja încărcat poate fi randat din cache și nu-ți spune nimic.

Dacă blocajul persistă, mută-te un salt spre exterior și verifică tabela de stări a acelui dispozitiv.