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'
किसी भी बदलाव के बाद दोनों सहकर्मियों को फिर से शुरू करें, क्योंकि ये विकल्प शुरुआत में एक बार पढ़े जाते हैं और एक सिरे को फिर से लोड करने से पुराने सत्र के पूरे जीवनकाल तक जोड़ी असंगत रहती है। अगर तैनाती अभी बिना दिशा कॉन्फ़िगर किए काम कर रही है, तो एक सहकर्मी पर सेटिंग जोड़ने से वही विफलता दोबारा बनती है जिससे आपने शुरुआत की थी; या तो दोनों को रहने दें या दोनों को कॉन्फ़िगर करें। एक बार में एक सिरा बदलें और पिछली फ़ाइल रखें, ताकि रिग्रेशन पुनर्निर्माण नहीं, दो मिनट का वापसी हो।
हर सिरे के लिए तंत्र, कुंजी फ़ाइल और दिशा तैनाती नोट्स में दर्ज करें, क्योंकि वरना अगला व्यक्ति दो समान फ़ाइलें पढ़ेगा और मान लेगा कि संख्याएँ एक-दूसरे से मेल खानी चाहिए। दिशा समन्वय का विवरण है, सुरक्षा उन्नयन नहीं: यह नियंत्रण चैनल की दो दिशाएँ अलग करती है और और कुछ नहीं करती।