Azure OpenVPN सुरंग लगभग हर साठ सेकंड में क्यों टूटती है

सुरंग अपना हैंडशेक पूरा करती है, लगभग एक मिनट तक ट्रैफ़िक ढोती है और फिर दोबारा जुड़ती है। यह क्रम आम संदिग्ध को बाहर कर देता है, क्योंकि पोर्ट को अवरुद्ध करने वाला फ़ायरवॉल सत्र को नहीं, हैंडशेक को रोकता। आपके पास जो है वह जीवंतता को लेकर असहमति है: एक पक्ष ने तय किया कि दूसरा चुप हो गया और एक चलती सुरंग को ढहा दिया। लॉग की पंक्ति बताती है कौन-सा पक्ष, और वही सुधार चुनती है।

किसी भी टाइमर को छूने से पहले वह पंक्ति पढ़ें।

मिथक: रास्ते में कुछ सुरंग को अवरुद्ध कर रहा है

अगर पोर्ट अवरुद्ध होता, तो कनेक्शन शुरू में ही विफल हो जाता और विफल रहता। बार-बार दोहराने वाला चक्र इसका मतलब है कि नियंत्रण संदेश बह रहे हैं, सत्र बन रहे हैं, और बातचीत में बाद में कुछ लगातार समाप्त हो रहा है। अवरोधन चुप्पी पैदा करता है, और यह लय पैदा करता है।

लय ही उपयोगी सुराग है। टाइमर इसे पैदा करते हैं; पैकेट खोना शायद ही कभी।

टाइमर से पहले डिस्कनेक्ट का कारण पढ़ें

OpenVPN अपने कारण का नाम बताता है, और हर नाम किसी अलग उपप्रणाली की ओर इशारा करता है। Session invalidated: KEEPALIVE_TIMEOUT एक समाप्त होता टाइमर है, इसलिए दोनों सिरों पर ping और ping-restart मानों की तुलना करें। AUTH_FAILED क्रेडेंशियल या प्रमाणपत्र की स्थिति है, और कोई टाइमर बदलाव मदद नहीं करेगा। TLS त्रुटि का मतलब है कि दोनों पक्ष keepalive चरण तक कभी पहुँचे ही नहीं।

कनेक्ट का समय, डिस्कनेक्ट का समय और यह कि अंतराल सेकंड तक स्थिर है या नहीं, दर्ज करें। वही एक माप निर्धारित समय-सारणी को संयोग से अलग करता है।

स्थिर अंतराल टाइमर है। सरकता अंतराल अधिक संभावित रूप से रास्ते की समस्या या स्थानांतरित सत्र है।

दो keepalive टाइमर जो कभी सहमत नहीं हुए

पोर्टल से निर्यात की गई प्रोफ़ाइलें कभी-कभी अभी भी सामुदायिक सर्वर टेम्पलेट से कॉपी की गई keepalive या ping-restart पंक्तियाँ रखती हैं। गेटवे अपनी मृत-साथी पहचान चलाता है और अपनी अपेक्षाएँ थोपता है, और दोनों समय-सारणियों का मेल होना ज़रूरी नहीं। जब वे असहमत होते हैं, क्लाइंट ऐसी समय-सारणी पर फिर से शुरू होता है जिसे गेटवे ने कभी स्वीकार नहीं किया।

दोनों मान एक ही नियंत्रण नहीं हैं। ping यह है कि क्लाइंट कितनी बार प्रतिध्वनि भेजता है, और ping-restart यह है कि सुरंग ढहाने से पहले वह बिना कुछ सुने कितनी देर प्रतीक्षा करता है। कम ping-restart वाली प्रोफ़ाइल और धीरे उत्तर देने वाला गेटवे हर शांत अवधि में फिर से शुरू होंगे, जो ठीक एक मिनट के चक्र का आकार है।

क्लाइंट की ओर सबसे छोटा बदलाव यह है कि प्रोफ़ाइल के शीर्ष स्तर पर, हर इनलाइन ब्लॉक से बाहर, टाइमरों को निष्क्रिय कर दें:

keepalive 0 0

सहेजें, प्रोफ़ाइल फिर से लोड करें, दोबारा कनेक्ट करें। मेमोरी में पहले से मौजूद सत्र पुराने मान रखता है, इसीलिए संपादन कभी-कभी ऐसा लगता है जैसे उसने कुछ नहीं किया।

प्रमाणपत्र का नाम आपके पैरों के नीचे से खिसक सकता है

Azure प्रमाणपत्र प्रमाणीकरण इस पर निर्भर है कि क्लाइंट आज गेटवे जो नाम प्रस्तुत करता है उस पर भरोसा करे। पुराने डाउनलोड में मौजूद verify-x509-name पंक्ति ऐसे नाम को पिन कर सकती है जिसे गेटवे के पुनर्निर्माण या प्रमाणपत्र नवीनीकरण ने तब से बदल दिया है, और यह बेमेल स्पष्ट त्रुटि के बजाय पुनःकनेक्शन लूप के रूप में सामने आता है। पंक्ति हटाने से कनेक्टिविटी लौट आती है, जो इसे अच्छा निदान और खराब स्थायी सुधार बनाता है, क्योंकि यह सत्यापन भी हटा देता है। सुरंग टिकने पर, गेटवे जो नाम वास्तव में प्रस्तुत करता है उसके साथ पंक्ति बहाल करें।

गेटवे संपादित करने से पहले उसी मशीन पर दूसरी पीढ़ी का क्लाइंट जाँचें। अगर एक क्लाइंट लूप में है और दूसरा टिका है, तो प्रोफ़ाइल समस्या नहीं है।

क्या बदलें, और किस क्रम में

इसके बाद स्थानांतरित सत्र जाँचें। एक प्रमाणपत्र साझा करने वाले दो उपकरण एक-दूसरे को बाहर धकेल सकते हैं, और नतीजा आवधिक दिखता है क्योंकि दोनों पक्ष दोबारा जुड़ते रहते हैं। उसी पहचान के लिए पॉइंट-टू-साइट सत्र रिकॉर्ड की तुलना करें जो बार-बार दिखाई देती है।

फिर कई मिनट तक लगातार ट्रैफ़िक चलाकर निष्क्रिय रास्ते को जाँचें। अगर ट्रैफ़िक बहते समय गिरना रुक जाए, तो महत्वपूर्ण टाइमर OpenVPN का नहीं, रास्ते के NAT उपकरण या लोड बैलेंसर का है।

गेटवे सेटिंग्स केवल इन चार परीक्षणों के बाद ही बदलनी चाहिए।