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 पंक्ति हटाना इस बात पर कुछ नहीं कहता कि आपकी तैनाती में संपीड़न निर्देश समर्थित है या स्वीकार्य, और दोनों निर्णय स्वतंत्र रूप से लेने चाहिए। कुछ जुड़ने तक एक साथ कई सुरक्षा-संबंधी सेटिंग्स हटाना वही तरीका है जिससे चलती हुई प्रोफ़ाइल एक अस्पष्ट प्रोफ़ाइल बन जाती है।

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