प्रोफ़ाइल डाउनलोड होती है, आयात होती है और फिर फ़ाइल की पंक्ति 12 पर Unrecognized option संदेश के साथ रुक जाती है जिसमें keysize का नाम आता है। खाते में कुछ नहीं बदला और सर्वर अब भी दूसरे क्लाइंट स्वीकार करता है। जो बदला है वह स्वयं क्लाइंट है: Ubuntu 24.04 OpenVPN 2.6 स्थापित करता है, जबकि निर्यात 2.4 के लिए लिखा गया था। मरम्मत कुछ हटाने की छोटी श्रृंखला है, और क्रम मायने रखता है क्योंकि हर पुराना विकल्प अगले को पढ़े जाने से पहले ही पार्सिंग रोक देता है।

फ़ाइल को छूने से पहले त्रुटि की पंक्ति पढ़ें

OpenVPN फ़ाइल और वह पंक्ति बताता है जहाँ पार्सिंग रुकी, इसलिए आप प्रति रन केवल एक समस्या ठीक कर सकते हैं। प्रोफ़ाइल को डेस्कटॉप ऐपलेट के बजाय टर्मिनल से शुरू करें, क्योंकि ऐपलेट आमतौर पर stderr निगल जाता है और पंक्ति संख्या ही एकमात्र भरोसेमंद संकेत है जो आपको मिलता है: sudo openvpn --config /etc/openvpn/client/provider.ovpn। उस पंक्ति को ठीक करें, फिर चलाएँ, और उम्मीद करें कि अगली विफलता किसी दूसरे विकल्प का नाम लेगी।

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

तीन विफलता वर्ग, तीन अलग मरम्मतें

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

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

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

2.6 ने जो विकल्प हटाए, उन्हें इस क्रम में हटाएँ

इनमें से हर पंक्ति अपने आप पार्सिंग रोक देती है, इसलिए क्लाइंट उन्हें एक-एक करके बताता है। सूची में नीचे बढ़ें और हर हटाने के बाद फिर चलाएँ।

पहले keysize हटाएँ, क्योंकि इसका कोई आधुनिक समकक्ष नहीं है और इसकी उपस्थिति आमतौर पर ऐसा साइफ़र दर्शाती है जिसे मौजूदा क्लाइंट वैसे भी अस्वीकार करता है। फिर ncp-disable हटाएँ, जो साइफ़र बातचीत नियंत्रित करता था, 2.5 में अप्रचलित हुआ और 2.6 में नहीं है। ns-cert-type server को remote-cert-tls server से बदलें, जो समर्थित जाँच के ज़रिए वही इरादा व्यक्त करता है। 2.6 परिवर्तन इतिहास शेष हटाने को उनके प्रतिस्थापनों के साथ सूचीबद्ध करता है, इसलिए जो कुछ भी पार्सर अब भी अस्वीकार करता है उसका दस्तावेज़ीकृत उत्तर मौजूद है।

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

BF-CBC को केवल सीमित बैकअप के रूप में चलाएँ

कुछ प्रदाता अब भी BF-CBC पर समाप्त करते हैं, जिस पर OpenVPN 2.6 बिना मदद के बातचीत नहीं करेगा क्योंकि साइफ़र का ब्लॉक 64 बिट का है। सीमित मरम्मत बैकअप सूची और पुराना OpenSSL प्रदाता है, पूरे क्लाइंट को डाउनग्रेड करना नहीं।

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

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

हर चीज़ के जवाब के रूप में --compat-mode की ओर न बढ़ें। यह एक साथ कई व्यवहार बदलता है, जिनमें बातचीत और पुनः बातचीत के डिफ़ॉल्ट भी शामिल हैं, इसलिए आप कभी नहीं जानेंगे कि कौन-सा बदलाव मायने रखता था। ऊपर दी गई तीन स्पष्ट पंक्तियों को प्राथमिकता दें, क्योंकि हर एक अपना प्रभाव स्वयं बताती है।

उस प्रोफ़ाइल से सत्यापित करें जिसे क्लाइंट वास्तव में लोड करता है

आयात किए गए कनेक्शन अक्सर सिस्टम निर्देशिका में कॉपी हो जाते हैं, इसलिए आपके डाउनलोड फ़ोल्डर की फ़ाइल संपादित करने से कुछ भी नहीं बदल सकता। वह प्रति खोजें जो चलती है: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn। फिर टनल शुरू करें और वह लॉग पंक्ति पढ़ें जो बताती है कि वास्तव में कौन-सा डेटा चैनल साइफ़र चुना गया। बैकअप पर हैंडशेक पूरा करने वाला कनेक्शन आपको बताता है कि सर्वर ने कभी कुछ आधुनिक पेश नहीं किया।

ऐसे नेटवर्क से परीक्षण करें जो प्रदाता के अपेक्षित नेटवर्क से अलग हो, ताकि कोई कैप्टिव पोर्टल या फ़िल्टर किया गया अतिथि नेटवर्क प्रोफ़ाइल की खराबी का रूप न धारण करे। किसी भी सहायता अनुरोध के साथ क्लाइंट संस्करण लिखें।

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

संबंधित लेख