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 जोड़ने के बाद निष्क्रिय परिदृश्य पहले जैसा ही दोहराएँ। फिर ढकी हुई ऐप्लिकेशन से सचमुच नया अनुरोध करें। पहले से लोड किया गया ब्राउज़र टैब कैश से दिख सकता है और आपको कुछ नहीं बताता।

अगर रुकावट बनी रहे, तो एक हॉप बाहर जाएँ और उस डिवाइस की स्टेट टेबल जाँचें।