OpenVPN प्रोफाइलबाट key-method हटाउँदा केही पनि बदलिँदैन

वर्षौंदेखि चलेको प्रोफाइल अचानक सुरु हुन इन्कार गर्छ, र सन्देशले कसैले थपेको सम्झना नभएको निर्देशनको नाम लिन्छ: key-method. अर्को खोज परिणामले अनुकूलताका लागि key-method 2 थप्न सुझाव दिन्छ, जुन अर्को युगको सल्लाह हो। त्यो लाइन अस्वीकार गर्ने पार्सर हालको हो, र त्यसमा यस्तो विकल्प नै छैन। लाइन हटाउँदा सुरुवात ठीक हुन्छ, र दुई पक्षले सत्रलाई कसरी सुरक्षित राख्छन् भन्नेमा केही पनि बदलिँदैन।

प्रोफाइलमा के छ र प्रोटोकलले वास्तवमा के गर्छ भन्नेबीचको यही खाडल यहाँको पूरै विषय हो, र यसले मानिसहरूले एकै समयमा गर्ने अरू धेरै सम्पादन पनि व्याख्या गर्छ। ती सम्पादनहरू प्रायः एउटै बन्डलमा किन आउँछन् भन्ने पनि यसले व्याख्या गर्छ।

लक्षण पार्स त्रुटि हो, ह्यान्डशेक असफलता होइन

कुनै पनि प्याकेट पठाउनुअघि विकल्पहरू पढिन्छन्। अज्ञात निर्देशन भएको प्रोफाइल त्यो चरणमा असफल हुन्छ, त्यसैले प्रक्रिया कहिल्यै सञ्जालसम्म पुग्दैन र कहिल्यै ह्यान्डशेक त्रुटि उत्पन्न गर्दैन। शब्दावलीले प्रायः विकल्प र फाइल पहिचान गर्छ, जसले यसलाई कारणसँग जोड्न सजिलो असफलताहरूमध्ये एक बनाउँछ। यसमा कुनै प्याकेट, मार्ग वा फायरवाल संलग्न छैन।

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

सन्देशले निर्देशनको नाम लिएमा निदान सकियो: फाइलमा यो बिल्डले स्वीकार नगर्ने केही छ। सन्देशले बरु फाइल मार्गको नाम लिएमा समस्या हराएको include वा कुञ्जी हो, जुन त्यही सुरुवाती चरणको अर्को भाग हो।

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

निर्देशन र प्रसारण ढाँचा दुई फरक कुरा हुन्

पुरानो key-method विकल्पले TLS कुञ्जी-आदानप्रदान कसरी ढाँचाबद्ध हुन्छ भन्ने छान्थ्यो, र आधुनिक आदानप्रदान त्यो विकल्पले कुनै बेला मागेको बहु-प्याकेट विधि हो। विकल्प हट्यो किनभने यसले अब केही पनि छान्दैनथ्यो; यसले नाम दिएको ढाँचा एकमात्र बन्यो। त्यसैले लाइन हटाउँदा सत्र पहिलेजस्तै त्यही ढाँचामा रहन्छ। पाठ सम्पादनले यसलाई कुनै पनि दिशामा बदल्न सक्दैन।

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

उपयोगी जाँच भनेको संस्करण र पार्स गरिएको कन्फिगरेसन हो, फाइलमा शब्दको उपस्थिति होइन:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

के हटाउने, र कुन फाइलबाट

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

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

त्यसपछि इच्छित इन्स्टेन्स सुरु गर्नुहोस् र त्यसको सुरुवाती आउटपुट पढ्नुहोस्। श्रोता उपस्थित हुँदा सफा सुरुवात नै यो चरण सकिएको पुष्टि हो; त्यसपछिको क्लाइन्ट परीक्षणले अर्को प्रश्नको उत्तर दिन्छ।

अस्वीकृत प्रोफाइल र अस्वीकृत क्लाइन्ट एउटै जस्तो देखिन्छन्

दुई असफलताले समान समर्थन थ्रेड बनाउँछन् र फरक प्रमाण चाहिन्छ। आफ्नै कन्फिगरेसन अस्वीकार गर्ने सर्भर कहिल्यै सुरु हुँदैन, त्यसैले कुनै पनि क्लाइन्ट त्यसमा जोडिन सक्दैन। राम्ररी सुरु भएर एउटा क्लाइन्टलाई अस्वीकार गर्ने सर्भर चलिरहेको हुन्छ, र त्यसको लगमा कारण हुन्छ: प्रमाणपत्रको समस्या, क्लाइन्टले नस्वीकार्ने धकेलिएको विकल्प, साइफरको बेमेल।

हटाइएको विकल्प दोस्रो अवस्थाका लागि निदान होइन, र त्यसतर्फ लाग्नुले त्यही घण्टा दुई पटक बर्बाद गर्छ। क्लाइन्ट लगले सर्भरको अस्वीकृति देखाएमा त्यही अस्वीकृति पढ्नुहोस्; स्थानीय त्रुटि देखाएमा जाँच्नुपर्ने फाइल क्लाइन्ट प्रोफाइल हो। अब नरहेको निर्देशनतर्फ लाग्नुले दुवै अनुसन्धानलाई उत्तिकै ढिलो बनाउँछ।

ती लाइनले कहिल्यै जवाफ नदिएका अनुकूलता प्रश्नहरू

यो निर्देशनसँग घुम्ने प्रोफाइलहरू प्रायः कुनै निश्चित प्लेटफर्मको कथा बोक्छन्, र त्यो कथा प्राविधिक कारणभन्दा लामो हुन्छ। मोबाइल वा डेस्कटप क्लाइन्टलाई अझै पनि पूर्ण रूपमा समर्थित प्रोफाइल चाहिन्छ: विश्वसनीय प्रमाणपत्र शृंखला, दुवै छेउले स्वीकार गर्ने डाटा साइफर, दुवै छेउले लागू गर्ने नियन्त्रण-च्यानल मोड, र क्लाइन्टको बिल्डले अस्वीकार नगर्ने निर्देशनहरूको अभाव। यीमध्ये कुनै पनि पुरानो key-method लाइनको उपस्थिति वा अनुपस्थितिले निर्धारण गर्दैन।

कम्प्रेसन त्यही आकारको छुट्टै नीति प्रश्न हो। key-method लाइन हटाउँदा तपाईंको तैनाथीमा कम्प्रेसन निर्देशन समर्थित छ कि स्वीकार्य छ भन्नेबारे केही पनि भन्दैन, र दुवै निर्णय स्वतन्त्र रूपमा लिनुपर्छ। केही जोडिएसम्म एकैचोटि धेरै सुरक्षा-सम्बन्धी सेटिङ हटाउनु नै चलिरहेको प्रोफाइल अस्पष्ट प्रोफाइल बन्ने बाटो हो।

तपाईंले के हटाउनुभयो र किन भन्ने छोटो अभिलेख राख्नुहोस्: विकल्प, त्यसलाई अस्वीकार गर्ने संस्करण, र त्रुटि देखाउने आदेश। प्रोफाइल उत्तराधिकारमा पाउने अर्को व्यक्तिलाई ठ्याक्कै ती तीन तथ्य चाहिन्छ, र ती अहिले लेख्नु पछि पुनर्निर्माण गर्नुभन्दा सस्तो हुन्छ।