vpnc कमज़ोर साइफ़र त्रुटि: गेटवे नीति या डेस्कटॉप मरम्मत?

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

बहुत अलग प्रभाव वाली दो मरम्मतें

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

पैकेज सत्यापन पहला शिकार है: /usr/sbin/vpnc पर मौजूद फ़ाइल जो अब अपने पैकेज से मेल नहीं खाती, नियमित सुरक्षा अद्यतन को जाँच में बदल देती है। फिर अपग्रेड या तो रैपर को चुपचाप ऊपर लिख देते हैं या लागू होने से मना कर देते हैं, यह इस पर निर्भर करता है कि पैकेज प्रबंधक संशोधित फ़ाइलों को कैसे संभालता है। दोनों में से कोई परिणाम कनेक्शन लॉग में नहीं दिखता, इसलिए पहली घटना तक रैपर दृष्टिकोण आकर्षक बना रहता है। प्रोफ़ाइल में एक पंक्ति उस बाइनरी की तुलना में ढूँढना और हटाना बहुत आसान है जिसे बदलने की याद किसी को नहीं है।

पुराना स्विच वास्तव में क्या करता है

vpnc मैनुअल सिंगल-DES विकल्प को कमज़ोर-एन्क्रिप्शन सेटिंग के पक्ष में अप्रचलित के रूप में चिह्नित करता है, और एक अलग विकल्प का दस्तावेज़ीकरण करता है जो डेटा ट्रैफ़िक के लिए बिल्कुल भी एन्क्रिप्शन की अनुमति देता है। ये अलग परिणामों वाली अलग रियायतें हैं। इनमें से कोई भी आधुनिक गेटवे को ऐसी किसी चीज़ पर बातचीत करने को मजबूर नहीं करता जो वह अब नहीं देता।

मरम्मत चुनने से पहले विफलता का चरण पढ़ें। अस्वीकृत प्रस्ताव और अस्वीकृत पासवर्ड समान फ़्रंटएंड संदेश देते हैं लेकिन पूरी तरह अलग साक्ष्य देते हैं।

सीमित अपवाद कहाँ है

यदि कोई संगठन सीमित अवधि के लिए जानबूझकर पुराने सहकर्मी को स्वीकार करता है, तो अपवाद उसी सहकर्मी की प्रोफ़ाइल में है, मालिक, समीक्षा तिथि और समर्थित प्रोटोकॉल तक माइग्रेशन पथ के साथ। इसे वैश्विक पथ से बाहर रखना ही इसे सीमित कहने का पूरा अर्थ है।

गेटवे के मालिक से पुष्टि कराएँ कि सहकर्मी अब भी कौन से एल्गोरिदम प्रस्तावित करता है और उसकी जगह क्या लेता है। क्लाइंट फ़्लैग उस प्रस्ताव को ठीक नहीं कर सकता जो सर्वर अब नहीं भेजता, और जिस सर्वर माइग्रेशन की योजना किसी ने नहीं बनाई वह वर्कअराउंड से अधिक टिकेगा। समीक्षा तिथि अपवाद के साथ उसी टिकट में रखें, ताकि रियायत स्थायी होने के बजाय समाप्त हो।

बातचीत जाँचें, सिर्फ़ हरा आइकन नहीं

संवाद के मूड के बजाय चरण की पहचान करने वाले साक्ष्य इकट्ठा करें। नीचे दिए गए कमांड केवल पढ़ने के लिए हैं, और पहले दो दिखाते हैं कि वास्तव में कौन सा कॉन्फ़िगरेशन और संस्करण लागू है।

vpnc --version
vpnc --print-config /etc/vpnc/legacy.conf
dpkg -V vpnc
grep -n -E 'weak|1des|no-encryption' /etc/vpnc/legacy.conf

तीसरा कमांड ऐसी फ़ाइलों की रिपोर्ट करता है जो अब पैकेज से मेल नहीं खातीं, और इस तरह भूला हुआ रैपर खुद को घोषित करता है। चौथा उन रियायतों को दिखाता है जो प्रोफ़ाइल में हैं, ताकि अपवाद किसी कॉपी की गई फ़ाइल के ज़रिए चुपचाप दूसरी प्रोफ़ाइल में न फैल सके। बदलाव से पहले और बाद में दोनों चलाएँ, और आउटपुट को चैट विंडो के बजाय कनेक्शन प्रोफ़ाइल के साथ रखें।

डीबग आउटपुट को तब तक टिकट से बाहर रखें जब तक कोई उसे पढ़ न ले, क्योंकि मैनुअल चेतावनी देता है कि उच्चतम डीबग स्तर पासवर्ड सहित प्रमाणीकरण डेटा उगलता है। स्वीकृति का मानदंड क्लाइंट और गेटवे के बीच अधिकृत, समर्थित समझौता है, न कि अंततः हरा होने वाला मेनू आइटम। यदि सहकर्मी केवल टूटा हुआ एल्गोरिदम देता है, तो ईमानदार परिणाम समाप्ति तिथि वाला अपवाद या प्रतिस्थापन प्रोटोकॉल है, और वह निर्णय गेटवे के मालिक का है। निर्णय दर्ज करना प्रबंधित अपवाद और आकस्मिक नीति परिवर्तन के बीच का अंतर है।