opt-verify जोडल्याने तुमची OpenVPN सायफर त्रुटी का दुरुस्त होणार नाही

तुम्हाला opt-verify जोडण्याचा सल्ला सापडतो, तुम्ही ओळ जोडता, आणि सायफर त्रुटी जिथे होती तिथेच राहते। हा निकाल अपेक्षित आहे, कारण पर्यायाने कधीही सायफरवर वाटाघाटी केली नाही। ही पर्याय-सुसंगतीची तपासणी होती, 2.6 मध्ये अप्रचलित झाली आणि 2.7 मध्ये काढून टाकली, आणि त्यासह अजूनही पार्स होणाऱ्या प्रोफाइलने याद्वारे काहीही लागू केले नाही।

ओळ पूर्वी काय करत असे हे जाणून घेणे उपयुक्त आहे, तोच गहाळ तुकडा आहे असा निष्कर्ष काढण्यापूर्वी। इतिहास हे देखील स्पष्ट करतो की ते आता का मदत करू शकत नाही।

पर्याय पूर्वी काय लागू करत असे

2.6 चे मॅन्युअल opt-verify ला अप्रचलित म्हणून चिन्हांकित करते आणि पूर्वीचे वर्तन वर्णन करते: सर्व्हर अशा क्लायंटना वगळतो ज्यांचे घोषित पर्याय त्याच्याशी जुळत नाहीत, उपकरणाचा प्रकार आणि MTU यांसारख्या गोष्टींची तुलना करतो। ती तपासणी पर्याय-सुसंगतीची तपासणी सुरू राहण्यावरही अवलंबून असते, म्हणून disable-occ सह चालणाऱ्या सर्व्हरकडे ती सुरुवातीलाच नव्हती। तुलना कशापासून बनते हे लक्षात घ्या: दुसऱ्या बाजूची संरचना वर्णन करणारा मजकूर। डेटा चॅनेल कोणते सायफर वापरेल याबद्दल तो काहीही सांगत नाही।

फ्लॅग सायफर त्रुटी दुरुस्त करू शकत नाही याचे हे पहिले कारण आहे। सायफरची निवड data-ciphers धोरण आणि दोन्ही बाजू कशाला समर्थन देतात यावरून ठरते, आणि मजकूर-सुसंगतीची तपासणी ती यादी वाढवत नाही किंवा वाटाघाटी करत नाही। दुसरे कारण व्याप्ती आहे: तपासणी घोषित पर्याय सुसंगत दिसतात का याबद्दल आहे, त्यातून तयार होणाऱ्या मार्गाच्या गुणवत्तेबद्दल नाही।

2.7 ओळ पाहिल्यावर काय करते

2.7 मध्ये पर्याय नाही। पार्सर अजूनही नाव ओळखतो, म्हणून जुने प्रोफाइल वाक्यरचना त्रुटीशिवाय लोड होते, आणि ते पर्याय काढून टाकल्याचे नोंदवते, गुपचूप तो वगळत नाही। नाव ओळखणे आणि वर्तन लागू करणे वेगळ्या गोष्टी आहेत, आणि अजूनही फक्त पहिलीच घडते। काढण्याच्या टिपा कारण देतात: एकदा पॅरामीटर्सवर वाटाघाटी करता आली की, दोन्ही बाजू जोडणीवर सहमत असतानाही कायदेशीरपणे वेगळ्या पर्याय-स्ट्रिंग ठेवू शकतात।

म्हणून पार्स होणारे प्रोफाइल कोणतीही प्रवेश तपासणी झाल्याचा पुरावा नाही। जर तुमचा एकमेव संकेत क्लायंट जोडला गेला हा असेल, तर वाक्यरचना स्वीकारली गेली हे तुम्ही शिकलात।

अपयश प्रत्यक्षात कुठे राहते

काहीही बदलण्यापूर्वी पहिली ठोस त्रुटी जतन करा, कारण नंतरचे संदेश सहसा तिचे परिणाम असतात। डेटा-चॅनेल वाटाघाटीचे अपयश मंजूर सायफर धोरण आणि दोन्ही बाजू प्रत्यक्षात जाहीर करतात त्या क्षमतांशी संबंधित आहे। TLS आवृत्ती किंवा सूटचे अपयश नियंत्रण चॅनेलशी संबंधित आहे। प्रमाणपत्र नाकारण्यासाठी ओळख आणि विश्वास-साखळी आवश्यक आहे, सुसंगतीचा फ्लॅग नाही।

दोन्ही टोकांवरील इंजिनही ओळखा। डेस्कटॉप ॲप्लिकेशन तुम्ही चाचणी केलेल्या कमांड-लाइन बायनरीपेक्षा वेगळे बिल्ड समाविष्ट करू शकते, आणि पर्याय समर्थन त्यांच्यात वेगळे असते। प्रोफाइल आयात करणारा प्रत्येक प्रोग्राम सारखाच वागतो असे गृहीत धरण्याऐवजी त्या इंजिनचे दस्तऐवज पाहा।

फक्त ओळ नाही, हेतू बदला

जर जुन्या व्यवस्थापित सर्व्हरने खरोखर सुसंगती तपासणीवर अवलंबून राहिले असेल, तर अपग्रेडपूर्वी तो कोणती मर्यादा लागू करत होता ते नोंदवा। नवीन प्रोफाइलमध्ये दुर्लक्षित पर्याय ठेवल्याने ते धोरण टिकू शकत नाही, आणि ओळी अव्यवस्थितपणे पुसल्यानेही टिकणार नाही।

सर्व सायफर बंद आहेत अशा जुन्या सूचनेला प्रत्येक ऐतिहासिक अल्गोरिदम सक्षम करून उत्तर देऊ नका।

मंजूर दुरुस्तीनंतर, नवीन जोडणीवर वाटाघाटीचे निकाल तपासा आणि वापरकर्त्याला खरोखर आवश्यक असलेले ॲप्लिकेशन चाचणी करा। सर्व्हर आवृत्ती आणि प्रभावी धोरण त्या निकालाच्या बाजूला ठेवा, जेणेकरून पुढील व्यक्तीला काय ठरले हे दिसेल, फक्त काय स्वीकारले गेले ते नाही।

ध्येय म्हणजे समर्थित मर्यादा आणि कार्यरत प्रमाणित मार्ग, अजूनही पार्स होणारा जुना फ्लॅग नाही।