Az UDP-s VPN tétlenségben megáll: a tűzfal elfelejtette a folyamot

A VPN csatlakozik, működik egy ideig, majd abbahagyja a forgalom átengedését, miközben a kliens még munkamenetet mutat. Az újracsatlakozás megjavítja, ezért klienshibának tűnik. Általában egy tűzfal vagy NAT-eszköz dobta el a tétlen UDP-leképezést, és fogalma sincs róla, hogy az alagút még létezik.

A tünet elég következetes a diagnózishoz: tétlenség után jelentkezik, nem terhelés alatt.

Hogyan néz ki a tétlenségi megállás

Mérje meg, ne írja le. Jegyezze fel, mennyi ideig áll tétlenül az alagút, mielőtt a forgalom megáll, egy új kimenő csomag újraéleszti-e, és a kliens interfész megtartja-e a címét. Ha a kliens friss kérése működik, de egy meglévő folyamra adott válasz nem, a leképezés a gyanús. Ha semmi sem működik, amíg újra nem csatlakozik, a kliens munkamenet-állapota is elveszett.

Mindkettő a tétlenséghez kapcsolódik, és különböző javításokat igényel.

Írja fel az időket, mielőtt bármit módosít. Egy jelentés, hogy körülbelül tíz tétlen perc után megáll, ellenőrizhető, míg egy jelentés, hogy véletlenszerűen szakad meg, nem az. Ez a különbség dönti el, hogy időzítő vagy útvonal-módosítás után kutat.

Keresse meg az eszközt, amely elfelejtette

Több eszköz is tarthat állapotot ugyanahhoz a folyamhoz: a helyi útválasztó, egy felsőbb fordító, egy felhőhatár és a gazdagép tűzfala. Mindegyiknek saját időzítője van, és a legrövidebb nyer. Egy ötperces kiesés általában azt jelenti, hogy egy eszköz jóval a többi alatt van beállítva.

Ne feltételezze, hogy a dokumentált alapértelmezés az időkorlát az ön útvonalán. Ez egyetlen eszköz alapértelmezése.

• Otthoni útválasztó: gyakran percek, néha sokkal kevesebb.
• Felhő-NAT vagy terheléselosztó: keresse meg a dokumentált tétlenségi időkorlátot kifejezetten UDP-re.
• Gazdagép tűzfala: a netfilter követési időzítői folyamonként érvényesek.

Ellenőrizze az időzítőket a tényleges útvonalon

Linuxon a netfilter követési időzítői láthatók és állíthatók: sysctl net.netfilter.nf_conntrack_udp_timeout és net.netfilter.nf_conntrack_udp_timeout_stream. A második akkor érvényes, ha már mindkét irányban látszott forgalom, ezért egy létrejött alagút túlélhet egy puszta próbát.

RFC 4787 meghatározza az UDP NAT viselkedését és az ajánlott minimumokat. Ez az a hivatkozás, amelyet idézni kell, amikor egy szállító alapértelmezése szokatlanul rövidnek tűnik.

A keepalive és az újracsatlakozás különböző eszközök

A keepalive életben tartja a leképezést; az újracsatlakozás újraépít egy halott munkamenetet. Különböző hibákat oldanak meg, és nem felcserélhető sebességbeállítások. A WireGuard PersistentKeepalive beállítása fix időközönként csomagot küld, hogy nyitva tartsa a NAT-kötést. Az OpenVPN keepalive opciója ugyanezt a munkát végzi a maga módján. Egyik sem segít, ha a középső eszköz már elfelejtette a folyamot, és mindkét irányt eldobja.

A nagyon sűrű próbák munkát adnak hozzá anélkül, hogy a rossz határt javítanák.

Új kéréssel ellenőrizze, ne oldalújratöltéssel

Miután módosított egy időzítőt vagy hozzáadott egy keepalive-ot, ismételje meg a tétlenségi forgatókönyvet pontosan úgy, mint korábban. Utána indítson valóban új kérést a lefedett alkalmazásból. Egy már betöltött böngészőfül a gyorsítótárból jelenhet meg, és semmit sem mond önnek.

Ha a megállás megmarad, lépjen egy ugrással kifelé, és ellenőrizze annak az eszköznek az állapottábláját.