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 त्रुटि भेट्ने व्यक्ति फोरम पोस्टमा भेटिएको साइफर स्ट्रिङबाट नभई त्यही अभिलेखबाट सुरु गर्नेछ।