opt-verify जोड़ने से आपकी OpenVPN साइफ़र त्रुटि क्यों ठीक नहीं होगी

आपको opt-verify जोड़ने का सुझाव मिलता है, आप पंक्ति जोड़ते हैं, और साइफ़र त्रुटि ठीक वहीं रहती है जहाँ थी। यह नतीजा अनुमानित है, क्योंकि विकल्प ने कभी साइफ़र पर बातचीत नहीं की। यह विकल्प-संगति की जाँच थी, जो 2.6 में अप्रचलित हुई और 2.7 में हटाई गई, और जो प्रोफ़ाइल इसके साथ अब भी पार्स होती है, उसने इससे कुछ भी लागू नहीं किया।

यह जानना मदद करता है कि पंक्ति पहले क्या करती थी, इससे पहले कि आप निष्कर्ष निकालें कि यही गायब टुकड़ा है। इतिहास यह भी समझाता है कि अब यह मदद क्यों नहीं कर सकती।

विकल्प पहले क्या लागू करता था

2.6 का मैनुअल opt-verify को अप्रचलित बताता है और पहले का व्यवहार बताता है: सर्वर उन क्लाइंट्स को हटा देता है जिनके घोषित विकल्प उसके अपने विकल्पों से मेल नहीं खाते, और डिवाइस प्रकार तथा MTU जैसी चीज़ों की तुलना करता है। यह जाँच इस पर भी निर्भर है कि विकल्प-संगति की जाँच चालू रहे, इसलिए disable-occ के साथ चलने वाले सर्वर के पास यह शुरू से ही नहीं थी। ध्यान दें कि तुलना किससे बनती है: सामने वाले पक्ष के कॉन्फ़िगरेशन का वर्णन करने वाला पाठ। यह इस बारे में कुछ नहीं कहता कि डेटा चैनल कौन-सा साइफ़र इस्तेमाल करेगा।

यही पहला कारण है कि फ़्लैग साइफ़र त्रुटि ठीक नहीं कर सकता। साइफ़र का चयन data-ciphers नीति और दोनों पक्षों के समर्थन से तय होता है, और पाठगत संगति जाँच न उस सूची को बढ़ाती है और न ही बातचीत करती है। दूसरा कारण दायरा है: जाँच इस बारे में है कि घोषित विकल्प संगत दिखते हैं या नहीं, उस पथ की गुणवत्ता के बारे में नहीं जो नतीजे में बनता है।

2.7 पंक्ति देखकर क्या करता है

2.7 में विकल्प नहीं है। पार्सर अब भी नाम पहचानता है, इसीलिए पुरानी प्रोफ़ाइल बिना सिंटैक्स त्रुटि के लोड होती है, और यह बताता है कि विकल्प हटा दिया गया था, बजाय उसे चुपचाप छोड़ देने के। नाम पहचानना और व्यवहार लागू करना अलग बातें हैं, और अभी केवल पहला होता है। हटाने के नोट्स कारण बताते हैं: एक बार पैरामीटर पर बातचीत हो सके, तो दोनों पक्ष जुड़ाव पर सहमत होते हुए भी वैध रूप से अलग विकल्प-स्ट्रिंग रख सकते हैं।

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

विफलता वास्तव में कहाँ रहती है

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

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

सिर्फ़ पंक्ति नहीं, इरादा बदलें

अगर किसी पुराने प्रबंधित सर्वर ने सचमुच संगति जाँच पर निर्भर किया था, तो अपग्रेड से पहले यह दर्ज करें कि वह कौन-सी सीमा लागू कर रहा था। नई प्रोफ़ाइल में अनदेखा किया गया विकल्प रखना उस नीति को सुरक्षित नहीं रख सकता, और बेतरतीब ढंग से पंक्तियाँ मिटाना भी नहीं।

सभी साइफ़र बंद हैं — इस पुराने सुझाव का जवाब हर ऐतिहासिक एल्गोरिदम सक्षम करके न दें।

स्वीकृत सुधार के बाद, नए जुड़ाव पर वार्ता-परिणाम देखें और वह ऐप्लिकेशन जाँचें जिसकी उपयोगकर्ता को वास्तव में ज़रूरत है। सर्वर संस्करण और प्रभावी नीति उस परिणाम के साथ रखें, ताकि अगला व्यक्ति देख सके कि क्या तय हुआ, केवल यह नहीं कि क्या स्वीकार हुआ।

लक्ष्य एक समर्थित सीमा और काम करता प्रमाणित पथ है, ऐसा पुराना फ़्लैग नहीं जो अब भी पार्स होता है।