हर घंटे OpenVPN ड्रॉप: फिर से बातचीत या असली पुनः कनेक्शन?

साठ मिनट, या तीस, या सौ बीस: गोल अंतराल पर पड़ने वाला ड्रॉप लगभग कभी नेटवर्क नहीं होता। OpenVPN टाइमर के अनुसार डेटा चैनल की रक्षा करने वाली कुंजी सामग्री को नवीनीकृत करता है, और आपके अनुमान से छोटा टाइमर ठीक वैसा ही दिखता है जैसे लगातार विफल होता लिंक। उपयोगकर्ता टूटे कनेक्शन की रिपोर्ट करते हैं जबकि लॉग सफल कुंजी विनिमय की रिपोर्ट करता है। नीचे की मार्गदर्शिका उस नवीनीकरण को असली पुनःआरंभ से अलग करती है, वह मान पढ़ती है जो वास्तव में लागू है, और उसे बदलती है केवल तब जब लागत मेज पर आ जाती है।

चरण क्रम से करें, क्योंकि पहला तय करता है कि पृष्ठ का बाकी हिस्सा आप पर बिल्कुल लागू होता है या नहीं। आगे कूदेंगे तो आप एक शाम ऐसी खराबी के लिए टाइमर ट्यून करने में बिताएँगे जिसका उससे कोई संबंध नहीं है।

नरम रीसेट को पुनःआरंभ से अलग पहचानें

लॉग पंक्ति ही पूरा निदान है। पुनः बातचीत एक नरम रीसेट लिखती है और फिर उसी सुरंग के भीतर नया कुंजी विनिमय: इंटरफ़ेस अपना पता रखता है, मार्ग फिर से नहीं जोड़े जाते, और स्थापित TCP सत्र आमतौर पर विराम के साथ बचे रहते हैं। असली पुनःआरंभ सत्र को फाड़ देता है, इंटरफ़ेस को फिर से बनाता है, शायद दूसरा क्लाइंट पता देता है, और हर दीर्घकालिक कनेक्शन को मार देता है। दोनों घटनाएँ सामान्य हैं; उनमें से केवल एक कटी हुई कॉल की व्याख्या करती है।

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

संस्करण पंक्ति महत्वपूर्ण है क्योंकि लॉग की शब्दावली संस्करणों के बीच बदलती है, और 2.3 से याद रहा संदेश 2.6 में अलग ढंग से लिखा हो सकता है। किसी और के फ़ोरम अंश के बजाय अपना लॉग पढ़ें। मदद माँगते समय ठीक वही पंक्ति उद्धृत करें, क्योंकि पुनर्कथन उस विवरण को खो देता है जो घटना की पहचान करता है। यदि घटना के दौरान इंटरफ़ेस का पता अपरिवर्तित रहा और सत्र सूची बची रही, तो आप नवीनीकरण देख रहे हैं और शेष खंड लागू होते हैं।

प्रभावी टाइमर पढ़ें, अपनी फ़ाइल नहीं

reneg-sec डेटा चैनल की पुनः बातचीत के बीच के सेकंडों की संख्या है और इसका डिफ़ॉल्ट 3600 है। प्रत्येक पक्ष अपना मान रखता है, और दोनों में से छोटा ही वास्तव में नवीनीकरण शुरू करता है। यही एक नियम अधिकांश रिपोर्टों की व्याख्या करता है: बड़ी संख्या निर्धारित करने वाला क्लाइंट प्रोफ़ाइल फिर भी हर घंटे रीसेट होता है जबकि सर्वर डिफ़ॉल्ट रखता है।

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

क्लाइंट फ़ाइल से निष्कर्ष निकालने से पहले सर्वर का प्रभावी कॉन्फ़िगरेशन भी पढ़ें, जिसमें वह जो कुछ भी पुश करता है वह शामिल है। फिर विस्तार बढ़ाएँ और एक अंतराल को शुरू से अंत तक देखें: स्तर 3 पहले से ही पुनः बातचीत की पंक्तियाँ दिखाता है, और समय-चिह्न बताते हैं कि घटना हर 3600 सेकंड में दोहराती है या गतिविधि का अनुसरण करती है।

इसे वहीं बदलें जहाँ वह वास्तव में पुश होता है

प्रचलित इलाज क्लाइंट प्रोफ़ाइल में एक पंक्ति है, और लगभग आधे समय यह गलत जगह होती है। चूँकि पक्ष का छोटा मान जीतता है, टाइमर को शून्य पर सेट करने वाला क्लाइंट भी ऐसे सर्वर द्वारा फिर से बातचीत करा सकता है जो बदला नहीं।

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

जहाँ प्रोफ़ाइल केंद्रीय रूप से बनाई जाती हैं, तैनात प्रति के बजाय टेम्पलेट संपादित करें, वरना अगली प्राविज़निंग बारी उस मान को बहाल कर देगी जो आपने अभी हटाया। एक नहीं, दो अंतराल देखकर सत्यापित करें: एक शांत घंटा 7200 पर सेट टाइमर से भी मेल खाता है।

मिश्रित तैनाती में क्या होगा यह भी तय करें। यदि आप बदलाव पहले क्लाइंटों तक पहुँचाते हैं, तो एक खिड़की बचती है जिसमें सर्वर अभी भी नवीनीकरण शुरू करता है; यह हानिरहित है पर भ्रमित करने वाला है यदि आप पुष्टि के लिए लॉग देख रहे हैं। पहले उस पक्ष को बदलें जिसके पास छोटा मान है और लक्षण उसी बिंदु पर गायब हो जाएगा जहाँ आप अपेक्षा करते हैं।

पुनः बातचीत बंद करके आप क्या छोड़ते हैं

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

बंद करने का उचित मामला वह रीसेट है जो ऐसा कुछ तोड़ता है जिसे फिर से शुरू नहीं किया जा सकता: कटने वाली कॉल, फिर से स्थापित करना पड़ने वाला दूरस्थ डेस्कटॉप सत्र, शुरू से चलने वाला बैकअप। यदि विराम उपयोगकर्ताओं को अदृश्य है, तो डिफ़ॉल्ट रखने पर कुछ खर्च नहीं होता और आपको मिला कुंजी रोटेशन बना रहता है।

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

जब अंतराल कहीं और इशारा करे

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

उपभोक्ता राउटर, मोबाइल हॉटस्पॉट और कैरियर-ग्रेड NAT सभी निष्क्रिय UDP सत्रों की अवधि किसी को बताए बिना समाप्त कर देते हैं। वह विफलता घड़ी नहीं बल्कि निष्क्रियता का अनुसरण करती है, और यही संकेत है: दस शांत मिनटों के बाद गिरने वाला और एक घंटे स्थिर ट्रैफ़िक टिकने वाला सत्र पुनः बातचीत नहीं कर रहा।

चौथा बदलने से पहले तीन बातें लिखें: जो अंतराल आपने मापा, जो प्रभावी मान आपने पाया, और जिस कमांड ने उसे दिखाया। यदि टाइमर हिलने पर अंतराल हिलता है, तो तंत्र पहचान लिया गया है और समाधान ऊपर की अदला-बदली पर निर्णय है। यदि वह नहीं हिलता, तो सेटिंग वापस रखें और keepalive, NAT स्थिति तथा पैकेट हानि देखते रहें।