दर तासाला 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 स्थिती आणि पॅकेट हानी पाहत राहा.