Ubuntu अपग्रेड के बाद OpenVPN ने कनेक्ट होना क्यों बंद कर दिया?

पिछले सप्ताह जो VPN प्रोफ़ाइल काम कर रही थीं, वे Ubuntu रिलीज़ अपग्रेड के बाद टूट जाती हैं, और लॉग अपग्रेड का ज़िक्र शायद ही करता है। जिसका वह नाम लेता है वह विफल परत है: TLS हैंडशेक, डेटा चैनल के लिए तय किया गया साइफ़र, इंस्टॉल हुआ पैकेज, या वह OpenSSL प्रति जिसे बाइनरी शुरू होते समय लोड करती है। हर परत की अपनी त्रुटि-आकृति और अपनी मरम्मत है, इसलिए वर्गीकरण पहला काम है और संपादन दूसरा। लॉग उसका नाम लेने तक प्रोफ़ाइल को निर्दोष मानें।

कौन-सी परत विफल हुई: हैंडशेक, साइफ़र, पैकेज या लाइब्रेरी

प्रोफ़ाइल को छूने से पहले क्लाइंट का लॉग पढ़ें। आउटपुट की सबसे पहली त्रुटि ही परत की पहचान करती है; उसके बाद छपी हर बात आम तौर पर उसी पहली विफलता का परिणाम होती है। जब क्लाइंट बिलकुल शुरू ही न हो, तब VPN लॉग खोलने के लिए गलत फ़ाइल है।

प्रमाणपत्रों और हस्ताक्षरों की शिकायतें, या कुंजी की लंबाई के बारे में संदेश, नियंत्रण चैनल और उसे नियंत्रित करने वाली लाइब्रेरी नीति से आते हैं। लेकिन DEPRECATED OPTION से शुरू होने वाली चेतावनी डेटा-चैनल वार्ता से संबंधित है।

ऐसी पंक्ति Unrecognized option तीसरी श्रेणी है: नई बाइनरी अब वह निर्देश स्वीकार नहीं करती जो पुरानी सहती थी, इसलिए लाइब्रेरी ढीली करने के बजाय प्रोफ़ाइल फिर से लिखनी होगी। पैकेज विफलताएँ फिर अलग दिखती हैं क्योंकि वे किसी भी टनल कोड के चलने से पहले होती हैं। गायब बाइनरी, लोड न होने वाला प्लगइन, या गलत कोडनेम की ओर इशारा करता रिपॉज़िटरी — सभी वही आकृति देते हैं। चार लक्षण, देखने के चार स्थान, और मरम्मतों के बीच लगभग कोई ओवरलैप नहीं।

जब हैंडशेक विफल होता है, TLS नीति प्रमाणपत्र को अस्वीकार करती है

Ubuntu 22.04 ने सिस्टम को OpenSSL 3 पर ले जाया, और उस शाखा में डिफ़ॉल्ट सुरक्षा स्तर प्रमाणपत्र हस्ताक्षरों और कुंजी के आकार पर 20.04 से अधिक सख़्त है। पुराने डाइजेस्ट से हस्ताक्षरित CA प्रमाणपत्र, या मौजूदा सीमा से नीचे की कुंजी, अब हैंडशेक के दौरान विफल होती है। चूँकि अभी कुछ भी प्रमाणित नहीं हुआ, त्रुटि गलत पासवर्ड या मृत सर्वर जैसी लगती है।

संकीर्ण मरम्मत केवल इस कनेक्शन से एक साइफ़र स्ट्रिंग जोड़ती है। डेस्कटॉप एडिटर में प्रोफ़ाइल खोलें, उन्नत सेटिंग्स में जाएँ और DEFAULT:@SECLEVEL=0 को TLS साइफ़र फ़ील्ड में रखें। NetworkManager की कुंजी-फ़ाइल [vpn] के अंतर्गत वही मान लेती है:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

NetworkManager को पुनः आरंभ करें और फिर कनेक्ट करें, क्योंकि डेमॉन पार्स की गई प्रोफ़ाइल कैश करता है और अन्यथा अपने पास मौजूद प्रति ही उपयोग करता रहेगा। पंक्ति रखने से पहले जानें कि वह क्या करती है: यह सेटिंग साइफ़र का नाम नहीं बल्कि कई प्रमाणपत्र और कुंजी मानकों पर एक सीमा है, इसलिए इसे नीचे करने से अकेली प्रोफ़ाइल की स्वीकार्यता बढ़ती है। नोट करें कि किस सर्वर ने इसकी माँग की और जब ऑपरेटर वर्तमान सामग्री फिर जारी करे तब यह सेटिंग हटा दें। लेकिन /etc/ssl/openssl.cnf बदलना उस फ़ाइल को पढ़ने वाले हर प्रोग्राम के लिए वही सीमा तक पहुँचता है, जो VPN से कहीं आगे है।

OpenVPN 2.6 को वार्ता के लिए साइफ़र सूचीबद्ध चाहिए

Ubuntu 22.10 ने OpenVPN 2.6 भेजा, और उस संस्करण में --cipher स्वयं डेटा चैनल चुनना बंद कर देता है। साइफ़र को तय की गई data-ciphers सूची में भी होना चाहिए, वरना क्लाइंट अप्रचलन चेतावनी छापता है और फिर टनल ऊपर नहीं ला पाता।

उसी दौर का NetworkManager प्लगइन अब भी केवल पुराना निर्देश लिखता था। यह विवरण निदान को बाँटता है, क्योंकि हाथ से सुधरी प्रोफ़ाइल शेल से कनेक्ट हो सकती है और डेस्कटॉप एप्लेट से फिर भी विफल हो सकती है। सूची को कनेक्शन फ़ाइल में [vpn] के अंतर्गत जोड़ें:

data-ciphers=AES-256-CBC

वह मान उपयोग करें जो सर्वर घोषित करता है, न कि वह जो आपको याद है; AES-256-GCM देने वाला सर्वर केवल CBC नाम देने वाली क्लाइंट सूची से वार्ता नहीं करेगा। मैनेजर को पुनः आरंभ करें और फिर कनेक्ट करें, फिर शेल से प्रयास दोहराएँ और साइफ़र स्पष्ट रूप से वार्ता तथा फ़ॉलबैक दोनों के लिए दें:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

अगर वह आदेश टनल ऊपर लाता है, तो सर्वर, प्रमाणपत्र और क्रेडेंशियल सब स्वस्थ हैं, और केवल मैनेजर का संग्रहीत विकल्प ही शेष दोष है। keysize निर्देश के बारे में चेतावनी उसी सफ़ाई का हिस्सा है: उस पर टिप्पणी करें और मूल फ़ाइल प्रोफ़ाइल के पास रखें।

पैकेज और प्लगइन दोष VPN दोष जैसे दिखते हैं

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

VPN लॉग से पहले पैकेज मैनेजर की त्रुटि पढ़ें। अगर क्लाइंट कभी इंस्टॉल ही नहीं हुआ, तो प्रोफ़ाइल संपादन की कोई भी मात्रा हैंडशेक नहीं देगी।

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

वेंडर लाइब्रेरी नीति-त्रुटि के पीछे छिप सकती है

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

VPN पैकेज फिर से इंस्टॉल करने से यह नहीं बदलता कि कौन-सी लाइब्रेरी पहले मिलती है, और TLS स्तर नीचे करना ऐसी लाइब्रेरी तक नहीं पहुँच सकता जो कभी सिस्टम से नहीं आई। लोडर से पूछें कि बाइनरी वास्तव में किन क्रिप्टो ऑब्जेक्ट को हल करती है:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

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

पुराने क्लाइंट को पिन करना समय खरीदता है, समाधान नहीं

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

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

अगली बार जब रिलीज़ अपग्रेड के बाद VPN मर जाए, तो पाँच प्रश्न क्रम से पूछें: किस परत ने पहली त्रुटि दी, क्या TLS नीति ने प्रमाणपत्र अस्वीकार किया, क्या साइफ़र दोनों दिशाओं में वार्ता-योग्य है, क्या पैकेज और उसका प्लगइन वास्तव में इंस्टॉल हुए, और प्रक्रिया कौन-सी लाइब्रेरी लोड करती है। पाँचों के साफ़ लौटने के बाद ही डाउनग्रेड का अर्थ है।