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

तुम्ही काय काढले आणि का याची छोटी नोंद ठेवा: पर्याय, तो नाकारणारी आवृत्ती, आणि त्रुटी दाखवणारी कमांड. प्रोफाइल वारसा म्हणून घेणाऱ्या पुढील व्यक्तीला नेमकी ती तीन तथ्ये लागतील, आणि ती आता लिहिणे नंतर पुनर्बांधणी करण्यापेक्षा स्वस्त आहे.