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

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

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