OpenVPN कहता है कि ncp-disable अज्ञात है: इसकी जगह किसने ली?

क्लाइंट ncp-disable का नाम लेने वाली विकल्प त्रुटि के साथ शुरू होने से मना कर रहा है, जबकि प्रोफ़ाइल पिछली मशीन पर काम करती थी। उस संदेश का अर्थ यह नहीं है कि विकल्प की वर्तनी गलत है या एन्क्रिप्शन टूट गया है। इसका अर्थ है कि आपके सामने की बाइनरी इस निर्देश को बिल्कुल नहीं जानती, और इसके दो बहुत अलग कारण हैं। कौन-सा लागू होता है, यह तय करता है कि आप प्रोफ़ाइल संपादित करेंगे या क्लाइंट बदलेंगे।

त्रुटि नई बाइनरी से भी आ सकती है

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

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

openvpn --version आपके द्वारा परखी जा रही बाइनरी के लिए यह तय कर देता है। GUI क्लाइंट वह कमांड न दिखाए; उस स्थिति में उसकी about स्क्रीन या साथ आई लाइब्रेरी का संस्करण पढ़ें।

विकल्प वास्तव में क्या नियंत्रित करता था

यह निर्देश क्रिप्टोग्राफ़िक पैरामीटर की बातचीत बंद करता था, इसलिए दोनों सिरे cipher सेटिंग द्वारा संचालित पुराने चयन व्यवहार पर लौट जाते थे। इसने कभी एन्क्रिप्शन बंद नहीं किया, और कभी सुरंग को सादे टेक्स्ट में नहीं बदला। इसे सुरक्षा स्विच के रूप में पढ़ना पहला ग़लत मोड़ है, और यह ऐसे बदलावों की ओर ले जाता है जो कनेक्शन को बेहतर की जगह ख़राब कर देते हैं।

बातचीत मौजूद होने पर समतुल्य सवाल यह है कि हर पक्ष कौन-से सिफ़र इस्तेमाल करने को तैयार है। यह नीति का सवाल है, और नीति 2.5 से आगे data-ciphers में रहती है।

पुराना नाम ncp-ciphers 2.4 का है। दोनों नामों को पीयर के बीच मिलाना एकतरफ़ा बातचीत विफलता का आम स्रोत है। दोनों को रखने वाली प्रोफ़ाइल वह प्रोफ़ाइल है जिसे दो लोगों ने अलग-अलग समय पर संपादित किया।

नीति बदलें, वर्तनी नहीं

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

प्रोफ़ाइल को उसके मालिक के माध्यम से अपडेट करें। अप्रचलित निर्देश छिपाने के लिए ignore विकल्प जोड़ना नीति के सवाल को अनुत्तरित छोड़ देता है।

अगर किसी पुराने पीयर को वाकई संगतता प्रबंधन चाहिए, तो उसे उसी परिनियोजन तक सीमित रखें। आधुनिक पीयर जोड़ने के लिए अप्रचलित व्यवहार को वैश्विक रूप से बहाल करना पूर्व शर्त नहीं है। अपवाद को उस पीयर का नाम लेना चाहिए जिसके लिए वह मौजूद है।

सिफ़र सूची जैसी दिखने वाली दो पंक्तियाँ, जो सूची नहीं हैं

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

दूसरी शाखा के लिए लिखी गाइड से सूची कॉपी करने के बजाय लक्ष्य बाइनरी पर openvpn --show-ciphers से स्वीकृत नाम जाँचें। रिलीज़ के बीच सूची बदलती है। एक शाखा में मान्य नाम दूसरी में ज़रूरी नहीं कि मान्य हो।

अगर लक्ष्य प्रदर्शन तुलना था, तो एल्गोरिदम और कार्यभार दर्ज करें। CBC पर जाना एन्क्रिप्शन के अनुपस्थित होने का माप नहीं है।

जाँचें कि कनेक्शन ने वास्तव में क्या तय किया

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

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