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

तिसरा आदेश आता पॅकेजशी न जुळणाऱ्या फाइलींची नोंद करतो, आणि अशा प्रकारे विसरलेला रॅपर स्वतःची जाहिरात करतो। चौथा प्रोफाइल वाहत असलेल्या सवलती दाखवतो, जेणेकरून अपवाद कॉपी केलेल्या फाइलमार्फत गुपचूप दुसऱ्या प्रोफाइलमध्ये पसरू शकणार नाही। बदलापूर्वी आणि नंतर दोन्ही चालवा, आणि आउटपुट चॅट विंडोमध्ये नाही तर कनेक्शन प्रोफाइलसोबत ठेवा।

डीबग आउटपुट कोणी वाचेपर्यंत तिकिटांबाहेर ठेवा, कारण मॅन्युअल इशारा देते की सर्वोच्च डीबग स्तर पासवर्डसह प्रमाणीकरण डेटा बाहेर टाकतो। स्वीकृतीचा निकष म्हणजे क्लायंट आणि गेटवे यांच्यातील अधिकृत, समर्थित करार, शेवटी हिरवा होणारा मेनू आयटम नाही। जर पीअर फक्त तुटलेला अल्गोरिदम देत असेल, तर प्रामाणिक निकाल समाप्ती तारखेसह अपवाद किंवा बदली प्रोटोकॉल आहे, आणि तो निर्णय गेटवेच्या मालकाचा आहे। निर्णय नोंदवणे हे व्यवस्थापित अपवाद आणि अपघाती धोरण बदल यातील फरक आहे।