हरेक घण्टाको 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 क्लाइन्टलाई पूरै तल झार्छ। लगमा कतै पनि पुनर्वार्ता नभएको निष्क्रिय ड्रप यिनै वा आफ्नै तालिकाअनुसार UDP म्यापिङको अवधि सकाउने NAT यन्त्रको हो।

उपभोक्ता राउटर, मोबाइल हटस्पट र क्यारियर-ग्रेड NAT सबैले निष्क्रिय UDP सत्रहरू कसैलाई नभनी अवधि सकाउँछन्। त्यो असफलता घडी होइन, निष्क्रियतालाई पछ्याउँछ, र त्यही सङ्केत हो: दस शान्त मिनेटपछि टुट्ने र एक घण्टा स्थिर ट्राफिक टिक्ने सत्र पुनर्वार्ता गर्दै छैन।

चौथो बदल्नु अघि तीन कुरा लेख्नुहोस्: नापिएको अन्तराल, फेला परेको लागू मान, र त्यो देखाउने आदेश। टाइमर सर्दा अन्तराल पनि सर्छ भने विधि पहिचान भयो र उपचार माथिको साटासाटबारे निर्णय हो। नसर्ने भए सेटिङ फर्काएर राख्नुहोस् र keepalive, NAT अवस्था र प्याकेट हानि हेर्दै रहनुहोस्।