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 धोरणाने प्रमाणपत्र नाकारले का, सायफर दोन्ही दिशांनी वाटाघाटीयोग्य आहे का, पॅकेज व त्याचे प्लगइन खरोखर स्थापित झाले का, आणि प्रक्रिया कोणती लायब्ररी लोड करते। पाचही स्वच्छ परत आल्यावरच आवृत्ती खाली आणण्यास अर्थ आहे।