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 जोडल्यानंतर निष्क्रिय परिस्थिती पूर्वीप्रमाणेच पुन्हा करा। मग व्यापलेल्या अनुप्रयोगातून खरोखर नवीन विनंती करा। आधीच लोड झालेला ब्राउझर टॅब कॅशमधून दिसू शकतो आणि तुम्हाला काहीच सांगत नाही।

थांबा कायम राहिला तर एक हॉप बाहेर जा आणि त्या उपकरणाची स्थिती सारणी तपासा।

संबंधित लेख