OpenVPN TLS सिफर त्रुटि: पहले दोनों पक्षों की तुलना करें

«कोई साझा सिफर नहीं» त्रुटि एक ही सेटिंग बदलने जैसी लगती है, और ज़्यादातर लोग जो सेटिंग बदलते हैं वही ग़लत है। OpenVPN TLS हैंडशेक करने वाले नियंत्रण चैनल के लिए और टनल के भीतर पैकेट ले जाने वाले डेटा चैनल के लिए अलग नीतियाँ रखता है, और त्रुटि पहले का नाम लेती है जबकि लोग दूसरे को संपादित करते हैं। प्रत्येक पक्ष क्या अनुमति देता है, सही क्रम में तुलना करना अनुमान को दो या तीन निर्णयों में बदल देता है: संस्करण, फिर सूट सूची, फिर क्रेडेंशियल।

यह क्रम ग़लत हो तो ऐसी सूची में AES नाम जोड़ने में एक घंटा बर्बाद हो सकता है जिसे कभी देखा ही नहीं गया।

दो सिफर सूचियाँ, और हैंडशेक तोड़ती है केवल एक

नियंत्रण चैनल TLS सत्र पर बातचीत करता है, और उसकी नीति इससे लिखी जाती है: tls-cipher TLS 1.2 के लिए और tls-ciphersuites TLS 1.3 के लिए। डेटा चैनल अलग से इससे कॉन्फ़िगर होता है: data-ciphers, जहाँ असंगति ऐसा कनेक्शन बनाती है जो स्थापित होता है और फिर ट्रैफ़िक पार नहीं कर पाता। दोनों ऐसी त्रुटियाँ देते हैं जो सिफर का ज़िक्र करती हैं, इसलिए वे आपस में मिल जाती हैं। जो हैंडशेक कभी पूरा नहीं होता वह नियंत्रण चैनल की ओर इशारा करता है, जबकि स्थापित टनल जो पैकेट गिराती है वह डेटा चैनल की ओर।

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

सूट की तुलना से पहले संस्करणों की तुलना करें

TLS 1.2 तक सीमित पक्ष और 1.3 आवश्यक मानने वाला पक्ष कोई संस्करण साझा नहीं करते, और कोई सिफर स्ट्रिंग उसे नहीं जोड़ती। दोनों ओर tls-version-min और tls-version-max दर्ज करें, या उपयोग किए जा रहे बिल्ड के डिफ़ॉल्ट, क्योंकि किसी डिस्ट्रिब्यूशन की OpenSSL नीति न्यूनतम सीमा बढ़ा सकती है और कोई OpenVPN विकल्प यह नहीं कहेगा। यदि एक पक्ष उपकरण या तीसरे पक्ष का क्लाइंट है, तो उसकी विंडो वही है जिसकी उसका फ़र्मवेयर अनुमति देता है। विंडो के ओवरलैप होने के बाद ही सूट तुलना का कोई अर्थ है।

उन रिकॉर्ड में वास्तविक बाइनरी के नाम भी होने चाहिए। कमांडलाइन openvpn आपके लैपटॉप पर ज़रूरी नहीं कि वही क्लाइंट हो जो आयातित प्रोफ़ाइल संभालता है।

TLS 1.2 और TLS 1.3 की सूचियाँ आपस में नहीं मिलतीं

TLS 1.2 सूट के नाम ऐसे दिखते हैं: ECDHE-RSA-AES256-GCM-SHA384 और वे tls-cipher में जाते हैं, जो OpenSSL सिफर स्ट्रिंग लेता है। TLS 1.3 सूट के नाम ऐसे होते हैं: TLS_AES_256_GCM_SHA384 और वे tls-ciphersuites में जाते हैं; 1.2 स्ट्रिंग में एक जोड़ने से 1.3 सूची कॉन्फ़िगर नहीं होती, और पार्सर पाठ को कभी मिलाए बिना स्वीकार कर सकता है। एक संस्करण के लिए सही फ़िल्टर दूसरे के बारे में कुछ नहीं कहता। लिख लें कि कौन-सी सूची किस संस्करण के लिए है।

openvpn --show-tls स्थानीय बिल्ड क्या समर्थन करता है यह छापता है, और वह सूची है, वादा नहीं: हो सकता है दूर का पक्ष उन सूटों की अनुमति न दे, और सक्रिय प्रोफ़ाइल उन्हें सक्षम न करे। इसका उपयोग ऐसे बिल्ड को बाहर करने के लिए करें जो कोई सूट दे ही नहीं सकता, फिर कॉन्फ़िगर की गई सूचियों की तुलना करें।

नए कनेक्शन पर बातचीत सिद्ध करें

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

यदि कोई स्वीकृत साझा कॉन्फ़िगरेशन नहीं है, तो उत्तर अपग्रेड या माइग्रेशन योजना है, कमज़ोर की गई नीति नहीं। tls-version-min घटाना, सत्यापन बंद करना या हर पुरानी सूट सक्षम करना उस सुरक्षा आवश्यकता को पूरा किए बिना अस्वीकृति हटा देता है जिसने उसे पैदा किया।

बदलाव टिकट में बातचीत किया गया संस्करण, सूट और डेटा सिफर दर्ज करें। अगली बार TLS त्रुटि से मिलने वाला व्यक्ति फ़ोरम पोस्ट में मिली सिफर स्ट्रिंग से नहीं, उसी रिकॉर्ड से शुरू करेगा।