UDP VPN apstājas dīkstāvē: ugunsmūris aizmirsa jūsu plūsmu

VPN pieslēdzas, kādu laiku strādā un tad pārstāj laist cauri datplūsmu, kamēr klients joprojām rāda sesiju. Atkārtota pieslēgšanās to salabo, tāpēc tas izskatās pēc klienta kļūdas. Parasti tas ir ugunsmūris vai NAT ierīce, kas izmeta neaktīvu UDP kartējumu un nezina, ka tunelis joprojām pastāv.

Simptoms ir pietiekami konsekvents diagnostikai: tas parādās pēc neaktivitātes, nevis slodzes laikā.

Kā izskatās apstāšanās dīkstāvē

Izmēriet to, nevis aprakstiet. Pierakstiet, cik ilgi tunelis ir dīkstāvē pirms datplūsmas apstāšanās, vai jauns izejošais pakets to atdzīvina un vai klienta saskarne joprojām tur savu adresi. Ja jauns klienta pieprasījums strādā, bet atbilde uz esošu plūsmu ne, kartējums ir aizdomās turamais. Ja nekas nestrādā, kamēr nepievienojaties no jauna, arī klienta sesijas stāvoklis ir zudis.

Abi ir saistīti ar dīkstāvi, un tiem vajadzīgi dažādi labojumi.

Pierakstiet laikus pirms kaut ko maināt. Ziņojums, ka tas apstājas pēc aptuveni desmit dīkstāves minūtēm, ir pārbaudāms, bet ziņojums, ka tas krīt nejauši, nav. Šī atšķirība nosaka, vai dzenaties pēc taimera vai maršruta izmaiņām.

Atrodiet ierīci, kas aizmirsa

Vairākas ierīces var glabāt stāvokli vienai un tai pašai plūsmai: vietējais maršrutētājs, augstāk esošs tulkotājs, mākoņa robeža un resursdatora ugunsmūris. Katrai ir savs taimeris, un uzvar īsākais. Piecu minūšu pārtraukums parasti nozīmē, ka viena ierīce ir konfigurēta krietni zemāk par pārējām.

Nepieņemiet, ka dokumentētā noklusējuma vērtība ir jūsu ceļa taimauts. Tā ir vienas ierīces noklusējums.

• Mājas maršrutētājs: bieži minūtes, dažreiz daudz mazāk.
• Mākoņa NAT vai slodzes balansētājs: meklējiet dokumentēto dīkstāves taimautu tieši UDP.
• Resursdatora ugunsmūris: netfilter izsekošanas taimeri attiecas uz katru plūsmu.

Pārbaudiet taimerus faktiskajā ceļā

Linux netfilter izsekošanas taimeri ir redzami un regulējami: sysctl net.netfilter.nf_conntrack_udp_timeout un net.netfilter.nf_conntrack_udp_timeout_stream. Otrais attiecas, tiklīdz datplūsma ir redzēta abos virzienos, tāpēc izveidots tunelis var pārdzīvot vienkāršu zondi.

RFC 4787 nosaka UDP NAT uzvedību un ieteicamos minimumus. Tas ir atsauce, uz ko atsaukties, ja piegādātāja noklusējums šķiet neparasti īss.

Keepalive un atkārtota pieslēgšanās ir dažādi rīki

Keepalive uztur kartējumu dzīvu; atkārtota pieslēgšanās pārbūvē mirušu sesiju. Tie risina dažādas kļūmes un nav savstarpēji aizstājami ātruma iestatījumi. WireGuard PersistentKeepalive iestatījums fiksētā intervālā sūta paketi, lai NAT saite paliktu atvērta. OpenVPN keepalive opcija dara to pašu savā veidā. Neviens nepalīdz, ja ierīce pa vidu jau ir aizmirsusi plūsmu un met abus virzienus.

Ļoti biežas zondes pievieno darbu, nelabojot nepareizo robežu.

Pārbaudiet ar jaunu pieprasījumu, nevis lapas pārlādi

Pēc taimera maiņas vai keepalive pievienošanas atkārtojiet dīkstāves scenāriju tieši kā iepriekš. Pēc tam izsūtiet patiešām jaunu pieprasījumu no pārklātās lietojumprogrammas. Jau ielādēta pārlūka cilne var tikt attēlota no kešatmiņas un neko nepasaka.

Ja apstāšanās turpinās, pārvietojieties vienu lēcienu uz āru un pārbaudiet tās ierīces stāvokļa tabulu.