जुनी .ovpn प्रोफाइल Ubuntu 24.04 वर अयशस्वी: कोणत्या ओळी काढायच्या

प्रोफाइल डाउनलोड होते, आयात होते आणि मग फाइलच्या 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 चा बदल-इतिहास उर्वरित काढण्या त्यांच्या पर्यायांसोबत सूचीबद्ध करते, म्हणून पार्सर अजूनही नाकारत असलेल्या प्रत्येक गोष्टीला नोंदवलेले उत्तर आहे.

पहिल्या संपादनापूर्वी मूळ प्रोफाइलची प्रत ठेवा. प्रदाते निर्याती पुन्हा तयार करतात, आणि अस्पर्शित फाइलशी तुलना केल्यास तुमचे बदल त्यांच्यापासून वेगळे करण्याचा सर्वात जलद मार्ग मिळतो. काढणीमुळे क्लायंट सुरू होत असेल पण बोगदा अजूनही अयशस्वी होत असेल, तर तुम्ही नेगोशिएशन वर्गात गेला आहात आणि उर्वरित ओळी कारण नाहीत. पुढच्या व्यक्तीला संपादने कोणत्या आवृत्तीसाठी आहेत हे कळावे म्हणून फाइलच्या नावात क्लायंट आवृत्ती ठेवा.

BF-CBC फक्त मर्यादित फॉलबॅक म्हणून चालू ठेवा

काही प्रदाते अजूनही BF-CBC वर संपतात, ज्याची वाटाघाटी OpenVPN 2.6 मदतीशिवाय करणार नाही कारण या सिफरला 64-बिट ब्लॉक आहे. तोच उपाय म्हणजे फॉलबॅक यादी आणि OpenSSL legacy प्रोव्हायडर, संपूर्ण क्लायंटचे डाउनग्रेड नाही.

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

पहिली ओळ legacy प्रोव्हायडर लोड करते जेणेकरून OpenSSL ती सिफर अजूनही तयार करू शकेल, दुसरी सपोर्ट करणाऱ्या पीअर्ससाठी आधुनिक वाटाघाटी ठेवते, आणि तिसरी फक्त सर्व्हरने त्यापेक्षा चांगले काही दिले नाही तेव्हा लागू होते. हे बोगद्याचे जाणीवपूर्वक कमकुवत करणे आहे, म्हणून ते का आहे हे फाइलच्या शेजारी नोंदवा. फॉलबॅक हा गंतव्य नसून पूल आहे, म्हणून त्याच वेळी प्रदात्याकडे पुन्हा तयार केलेली निर्यात मागा.

--compat-mode ला सर्वसमावेशक उत्तर म्हणून हात लावू नका. ते एकाच वेळी अनेक वर्तन बदलते, नेगोशिएशन आणि पुनर्नेगोशिएशन डीफॉल्टसह, त्यामुळे कोणता बदल महत्त्वाचा होता हे कधीच कळत नाही. वरच्या तीन स्पष्ट ओळींना प्राधान्य द्या, कारण प्रत्येक स्वतःचा परिणाम सांगते.

क्लायंट प्रत्यक्षात जी प्रोफाइल लोड करतो तिच्याशी पडताळा

आयात केलेले कनेक्शन बऱ्याचदा सिस्टम डिरेक्टरीत कॉपी होतात, त्यामुळे तुमच्या डाउनलोड फोल्डरमधील फाइल संपादित केल्याने काहीच बदलणार नाही. चालणारी प्रत शोधा: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. मग बोगदा सुरू करा आणि प्रत्यक्षात निवडलेल्या डेटा चॅनेल सिफरची नोंद देणारी लॉग ओळ वाचा. फॉलबॅकवर हँडशेक पूर्ण करणारे कनेक्शन सांगते की सर्व्हरने कधीही आधुनिक काही दिले नाही.

प्रदाता ज्या नेटवर्कची अपेक्षा करतो ते नसलेल्या नेटवर्कवरून चाचणी करा, जेणेकरून कॅप्टिव्ह पोर्टल किंवा फिल्टर केलेले गेस्ट नेटवर्क प्रोफाइलची त्रुटी असल्याचे भासवणार नाही. कोणत्याही सपोर्ट विनंतीसोबत क्लायंट आवृत्ती नोंदवा.

बोगदा उभा राहिल्यावर एक विनंती पाठवा जी त्यातूनच जायला हवी आणि एक जी जाऊ नये, मग रिझॉल्व्हरचे उत्तर अपेक्षेप्रमाणे बदलले का ते तपासा. प्रोफाइल आता पार्स होत असेल पण कनेक्शन अजूनही अयशस्वी होत असेल, तर तुम्ही सिंटॅक्स समस्या मागे सोडली आहे आणि त्रुटी मजकूर नवीन वर्गाचे नाव देईल. संपादित फाइल ज्या OpenVPN आवृत्तीसाठी आहे ते नाव देणाऱ्या टिपेसोबत आवृत्ती नियंत्रणात ठेवा.