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 त्रुटीला सामोरे जाणारी व्यक्ती फोरम पोस्टमध्ये मिळालेल्या सिफर स्ट्रिंगपासून नाही, त्या नोंदीपासून सुरुवात करेल।