UDP VPN निष्क्रिय हुँदा रोकिन्छ: फायरवालले तपाईंको प्रवाह बिर्स्यो

VPN जोडिन्छ, केही समय काम गर्छ र त्यसपछि क्लाइन्टले अझै सत्र देखाइरहेको बेला ट्राफिक पठाउन रोक्छ। फेरि जोड्दा यो ठीक हुन्छ, जसले यसलाई क्लाइन्टको बग जस्तो देखाउँछ। सामान्यतया यो फायरवाल वा NAT यन्त्र हो जसले निष्क्रिय UDP म्यापिङ फालेको छ र सुरुङ अझै अवस्थित छ भन्ने थाहा छैन।

लक्षण निदानका लागि पर्याप्त एकरूप छ: यो निष्क्रियतापछि देखिन्छ, भारमुनि होइन।

निष्क्रिय रोकावट कस्तो देखिन्छ

वर्णन गर्नुको सट्टा नाप्नुहोस्। ट्राफिक रोकिनुअघि सुरुङ कति समय निष्क्रिय रहन्छ, नयाँ बाहिर जाने प्याकेटले यसलाई फेरि जीवित बनाउँछ कि, र क्लाइन्ट इन्टरफेसले अझै आफ्नो ठेगाना राखेको छ कि लेख्नुहोस्। क्लाइन्टबाट नयाँ अनुरोध चल्छ तर विद्यमान प्रवाहको जवाफ चल्दैन भने म्यापिङ शंकास्पद हो। फेरि जोडुन्जेल केही पनि नचले क्लाइन्टको सत्र अवस्था पनि गइसक्यो।

दुवै निष्क्रियतासँग सम्बन्धित छन्, र तिनलाई फरक समाधान चाहिन्छ।

केही बदल्नुअघि समय लेख्नुहोस्। करिब दस निष्क्रिय मिनेटपछि रोकिन्छ भन्ने रिपोर्ट परीक्षणयोग्य छ, तर अनियमित रूपमा खस्छ भन्ने रिपोर्ट परीक्षणयोग्य छैन। यही भिन्नताले तपाईं टाइमरको पछि लाग्नुहुन्छ कि राउटिङ परिवर्तनको भन्ने निर्धारण गर्छ।

बिर्सेको यन्त्र खोज्नुहोस्

एउटै प्रवाहका लागि धेरै यन्त्रले अवस्था राख्न सक्छन्: स्थानीय राउटर, माथिको अनुवादक, क्लाउड सीमा र होस्ट फायरवाल। प्रत्येकको आफ्नै टाइमर छ, र सबैभन्दा छोटो जित्छ। पाँच मिनेटको अवरोध सामान्यतया एउटा यन्त्र अरूभन्दा धेरै तल कन्फिगर गरिएको अर्थाउँछ।

कागजातमा लेखिएको पूर्वनिर्धारित मान नै तपाईंको बाटोको समयसीमा हो भनी नमान्नुहोस्। त्यो एउटा यन्त्रको पूर्वनिर्धारित हो।

• घरायसी राउटर: प्रायः मिनेट, कहिलेकाहीँ धेरै कम।
• क्लाउड NAT वा लोड ब्यालेन्सर: UDP का लागि विशेष रूपमा कागजातमा लेखिएको निष्क्रिय समयसीमा हेर्नुहोस्।
• होस्ट फायरवाल: netfilter ट्र्याकिङ टाइमर प्रत्येक प्रवाहमा लागू हुन्छन्।

वास्तविक बाटोमा टाइमर जाँच्नुहोस्

Linux मा netfilter ट्र्याकिङ टाइमर देखिन्छन् र समायोजन गर्न सकिन्छ: sysctl net.netfilter.nf_conntrack_udp_timeout र net.netfilter.nf_conntrack_udp_timeout_stream। दोस्रो दुवै दिशामा ट्राफिक देखिएपछि लागू हुन्छ, त्यसैले स्थापित सुरुङ साधारण प्रोबभन्दा लामो बाँच्न सक्छ।

RFC 4787 ले UDP NAT व्यवहार र सिफारिस गरिएका न्यूनतम मान निर्धारण गर्छ। विक्रेताको पूर्वनिर्धारित असामान्य रूपमा छोटो देखिँदा उद्धृत गर्नुपर्ने सन्दर्भ यही हो।

Keepalive र पुनःजडान फरक औजार हुन्

Keepalive ले म्यापिङ जीवित राख्छ; पुनःजडानले मृत सत्र नयाँ बनाउँछ। ती फरक विफलता समाधान गर्छन् र ती अदलबदल गर्न मिल्ने गति सेटिङ होइनन्। WireGuard को PersistentKeepalive ले निश्चित अन्तरालमा प्याकेट पठाएर NAT बन्धन खुला राख्छ। OpenVPN को keepalive विकल्पले त्यही काम आफ्नै तरिकाले गर्छ। बीचको यन्त्रले प्रवाह बिर्सिसकेको र दुवै दिशा फालिरहेको भए कुनैले पनि मद्दत गर्दैन।

अत्यधिक बारम्बारका प्रोबले काम थप्छन् तर गलत सीमा सुधार्दैनन्।

पृष्ठ रिलोडले होइन, नयाँ अनुरोधले प्रमाणित गर्नुहोस्

टाइमर बदलेपछि वा keepalive थपेपछि निष्क्रिय परिदृश्य पहिलेजस्तै ठ्याक्कै दोहोर्याउनुहोस्। त्यसपछि समेटिएको एपबाट साँच्चै नयाँ अनुरोध गर्नुहोस्। पहिले नै लोड भएको ब्राउजर ट्याब क्यासबाट देखिन सक्छ र तपाईंलाई केही बताउँदैन।

रोकावट जारी रहे एक हप बाहिर सर्नुहोस् र त्यो यन्त्रको स्थिति तालिका जाँच्नुहोस्।