tls-auth key-direction: 0 आणि 1 वेगळे असावेत, जुळू नयेत
tls-auth सह दोन्ही टोकांना विरुद्ध दिशा हव्या, 0 आणि 1, किंवा दोन्हीने सेटिंग वगळावी. तीच संख्या अयशस्वी होते, आणि tls-crypt ती कधीही वापरत नाही.
बोगद्याची एक बाजू नियंत्रण चॅनेलवर अशा की स्लॉटने स्वाक्षरी करते जी दुसरी बाजू कधीही तपासत नाही, आणि एकही प्रमाणपत्र बदलण्याआधी कनेक्शन प्रमाणीकरण त्रुटीने मरते. tls-auth ची दिशा-विसंगती अशी दिसते, आणि ती निर्धारक आहे: तीच दोन फाइली प्रत्येक प्रयत्नात, कोणत्याही नेटवर्कवरून अयशस्वी होतात. लॉगमध्ये तुम्ही शोधत असलेल्या पर्यायाचे नाव नाही, म्हणून लोक कधीही न तुटलेल्या की पुन्हा तयार करतात आणि प्रमाणपत्रे पुन्हा जारी करतात. उपाय म्हणजे दोन्ही टोके पूरक करणे, किंवा दोन्ही द्विदिश ठेवणे, पडताळणी कमकुवत करणे नव्हे.
अयशस्वीता प्रमाणपत्रांपूर्वी येते
tls-auth सह दोन्ही सहकारी एकच सामायिक की ठेवतात आणि प्रत्येक त्यातून तयार झालेल्या दोन स्लॉटपैकी एक वापरतो: एक स्लॉट बाहेर जाणाऱ्या नियंत्रण पॅकेटवर स्वाक्षरी करतो, दुसरा येणाऱ्या पॅकेटची पडताळणी करतो. दिशा 0 आणि दिशा 1 या भूमिका उलट क्रमाने नेमतात, म्हणून HMAC तपासण्या जुळण्यासाठी जोडी पूरक असावी. एका बाजूला नेमणूक उलटली की प्राप्तकर्ता चुकीच्या स्लॉटमध्ये स्वाक्षरी शोधतो आणि पॅकेट नाकारतो. सत्र तिथेच संपते, म्हणून त्रुटी पॅकेट प्रमाणीकरणाशी आहे, प्रमाणपत्र साठवणीने तयार होणाऱ्या कशाशी नाही.
निर्धारकता निदानासाठी महत्त्वाची आहे, कारण वेळ किंवा मार्गाची समस्या वेगळी खूण सोडते: अधूनमधून तुटणे, एका दिशेची अयशस्वीता, किंवा फक्त विशिष्ट नेटवर्कवर मरणारे सत्र. दिशा-विसंगती प्रत्येक वेळी पहिल्या हातमिळवणीत अयशस्वी होते, आणि तीच दोन फाइली असलेल्या दुसऱ्या मशीनवरही तशीच अयशस्वी होते. --verb 4 वर लॉग वाचा आणि शेवटच्या ओळीऐवजी पहिले नाकारलेले पॅकेट शोधा. जर ते नाकारणे कोणत्याही प्रमाणपत्र देवाणघेवाणीपूर्वी होत असेल, तर सामायिक की आणि तिची दिशा तपासण्यासारख्या दोन गोष्टी आहेत.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
संख्या कुठे राहते
OpenVPN 2.6 पुस्तिका दिशेसाठी दोन ठिकाणे नोंदवते: की स्वतंत्र फाइलमध्ये असताना tls-auth चा दुसरा वितर्क, आणि की प्रोफाइलमध्ये इनलाइन असताना स्वतंत्र key-direction ओळ. दोन्ही समान मूल्य सेट करतात, म्हणून प्रोफाइलने एक रूप किंवा दुसरे वापरावे, कधीही दोन्ही नाही. वगळणेही एक पर्याय आहे, आणि ते दोन्ही सहकाऱ्यांना द्विदिश मांडणीत ठेवते जी कोणतीही बाजू दिशा न सांगता काम करते. एकाच संख्येचे दोन सहकारी त्या मांडणीत नाहीत: प्रत्येक एका स्लॉटमध्ये स्वाक्षरी आणि दुसऱ्यात पडताळणी अपेक्षितो, आणि दोन्ही ते एकाच पद्धतीने करतात.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
इनलाइन रूप स्वतःच्या ओळीवरील निर्देश आहे, की ब्लॉकच्या उघडण्याच्या टॅगवरील गुणविशेष नाही, आणि त्या टॅगला वितर्क जोडणे त्रुटी आहे, दिशा-बदल नाही. स्थानही महत्त्वाचे आहे: निर्देश ज्या ब्लॉकचा तो आहे त्याच्या बाहेर असतो, म्हणून ब्लॉकच्या आत लिहिलेले मूल्य की सामग्री म्हणून वाचले जाते. प्रोफाइलच्या वितरकाने हेतू केलेली मांडणी कॉपी करा, जोडी शोधून काढण्याऐवजी, कारण एका सर्व्हरविरुद्ध चालणारे प्रोफाइल कदाचित दुसऱ्या बाजूला आधीच प्रतिबिंबित झालेले असेल.
पर्याय काय अस्पर्श ठेवतो
तो अनुप्रयोग रहदारी एन्क्रिप्ट करत नाही. tls-auth नियंत्रण चॅनेलच्या पॅकेटभोवती HMAC ठेवतो, तर डेटा चॅनेल हातमिळवणीत वाटाघाटी केलेल्या सत्र कींद्वारे संरक्षित असते, म्हणून थ्रूपुट किंवा सिफरचा प्रश्न दिशा-संख्येशी काहीही संबंधित नाही. सेटिंग एन्क्रिप्शनचा दुसरा थरही जोडत नाही, आणि हाच गृहीतक लोकांना लांब की शोधायला पाठवतो.
ते tls-crypt वर लागू होत नाही, स्वतःचे पर्याय आणि की-हाताळणी असलेली दुसरी नियंत्रण चॅनेल यंत्रणा, आणि कोणत्याही सहकाऱ्याच्या प्रमाणपत्र ओळखीबद्दल काहीही सांगत नाही. म्हणून कार्यरत दिशा-जुळणी फक्त हे सिद्ध करते की दोन्ही टोके नियंत्रण चॅनेलचे प्रमाणीकरण कसे करावे यावर सहमत आहेत, विश्वास-साखळी पडताळली गेली हे नाही.
जोडी सरळ करा, मग पुन्हा जोडा
कोणतेही बदलण्यापूर्वी दोन्ही संरचना तुलना करा, कारण आधीच बरोबर असलेली बाजू संपादित केल्यास काम दुप्पट होते. खालील grep प्रत्येक फाइल कोणती यंत्रणा निवडते ते दाखवते; तपशीलवार रन नियंत्रण चॅनेल प्रमाणित झाले की नाही ते दाखवते. दोन्ही आउटपुट ठेवा, जेणेकरून पुढील बदल ज्ञात स्थितीशी तुलना करता येईल.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
कोणत्याही बदलानंतर दोन्ही सहकारी पुन्हा सुरू करा, कारण हे पर्याय सुरुवातीला एकदा वाचले जातात आणि एक बाजू पुन्हा लोड केल्यास जुन्या सत्राच्या संपूर्ण आयुष्यभर जोडी विसंगत राहते. जर तैनाती सध्या दिशा कॉन्फिगर न करता चालत असेल, तर एका सहकाऱ्यावर सेटिंग जोडल्यास तुम्ही सुरू केलेलीच अयशस्वीता पुन्हा निर्माण होते; एकतर दोन्ही राहू द्या किंवा दोन्ही कॉन्फिगर करा. एका वेळी एक टोक बदला आणि मागील फाइल ठेवा, जेणेकरून रिग्रेशन पुनर्निर्माण नव्हे, दोन मिनिटांचे पूर्वस्थितीत येणे असेल.
प्रत्येक टोकासाठी यंत्रणा, की फाइल आणि दिशा तैनाती नोंदींमध्ये लिहा, कारण अन्यथा पुढील व्यक्ती दोन सारख्या फाइली वाचेल आणि संख्या एकमेकांशी जुळल्या पाहिजेत असे गृहीत धरेल. दिशा समन्वयाचा तपशील आहे, सुरक्षा सुधारणा नाही: ती नियंत्रण चॅनेलच्या दोन दिशा वेगळ्या करते आणि दुसरे काहीही करत नाही.