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 नीतिले प्रमाणपत्र अस्वीकार गर्यो कि, साइफर दुवै दिशामा वार्तायोग्य छ कि, प्याकेज र त्यसको प्लगइन साँच्चै स्थापना भए कि, र प्रक्रियाले कुन पुस्तकालय लोड गर्छ। पाँचै सफा फर्किएपछि मात्र संस्करण तल झार्नुको अर्थ हुन्छ।