0x कि 0s? ipsec.secrets मा PSK ढाँचा बुझ्ने

एउटा क्लाइन्ट साझा कुञ्जीले प्रमाणीकरण गर्छ र अर्कोले त्यसलाई अस्वीकार गर्छ, तर तपाईंले टाँस्नुभएका अक्षर दुवैतिर एउटै देखिन्छन्। सम्भवतः ती एउटै अक्षर हुन्; फरक यत्ति हो कि फाइलले तिनीमा कुन डिकोडिङ नियम लागू गर्छ। उद्धरण चिन्हभित्रको स्ट्रिङ शब्दशः लिइन्छ, 0x बाट सुरु हुने टोकन हेक्साडेसिमलका रूपमा पढिन्छ, र 0s बाट सुरु हुने टोकन Base64 का रूपमा पढिन्छ। यी तीन लेखनमध्ये एउटाले मात्र तपाईंले चाहेको अर्थ दिन्छ, त्यसैले सुधार सामान्यतया राम्रो पासवर्ड होइन, रूपान्तरण हो।

लक्षण सिफरतिर होइन, इन्कोडिङतिर सङ्केत गर्छ

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

चरण नै सुराग हो। छानिएको प्रस्तावपछि आउने असफलताको अर्थ दुवै पक्ष कुञ्जी सामग्रीबाहेक सबैमा सहमत भए भन्ने हो, जबकि «कुनै प्रस्ताव छानिएन» नीति वा सिफर सेटसँग सम्बन्धित छ। पासवर्ड सही देखिँदा असफल हुने अखण्डता जाँच इन्कोडिङ असमञ्जसको देखिने अनुहार हो।

एउटा रहस्य, फाइलले त्यो पढ्न सक्ने तीन तरिका

चार बाइटको मानका लागि key1 हेक्साडेसिमल र Base64 एउटै बाइटका दुई पुनः-इन्कोडिङ हुन्, र सुरुका अक्षरले मात्र पार्सरलाई कुन राखेको छ भनी बताउँछन्। swanctl प्रमाणहरूले पनि त्यही परिपाटी पछ्याउँछन्, त्यसैले दुई इन्टरफेसबीच सारिएको मानले आफ्नो अर्थ तब मात्र जोगाउँछ जब त्यसको उपसर्ग सँगै जान्छ।

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

त्यो ब्लकका दुई विवरणले सबैभन्दा बढी समय लिन्छन्। हेक्साडेसिमल अङ्कले दुवै केस स्वीकार्छन्, त्यसैले 0x6b657931 र 0x6B657931 एउटै मान हुन्, तर विषम सङ्ख्याका अक्षर अस्वीकार नगरी चुपचाप गलत पढिन्छन्, जसले काटिएपछिको हरेक बाइट सार्छ। Base64 प्याडिङ मानकै भाग हो, त्यसैले अन्तिम = चिन्हबिना टाँसिएको स्ट्रिङ ठूलो स्वरमा असफल नभई फरक बाइटमा डिकोड हुन्छ।

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

Base64 पाठ कहाँबाट आउँछ

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

दुवै दिशा एक-एक आदेश हुन्, र जुन ठ्याक्कै क्रियाले भण्डारण गरिएको मान बनायो त्यसैका रूपमा तिनलाई टिकटमा राख्नु उपयुक्त हुन्छ। तिनलाई यो क्रममा चलाउनुहोस्:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

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

हरेक साथीले वास्तवमै कुन बाइट प्रयोग गर्छ भनी पुष्टि गर्नुहोस्

त्रुटिको स्ट्रिङबाट कारण अनुमान गर्नुको सट्टा पहिले डेमनको जडानबारे दृष्टिकोण र त्यसपछि प्रमाणीकरणको नतिजा पढ्नुहोस्। भण्डारण गरिएको लम्बाइ तुलना गर्नु छिटो तर्कसंगतता जाँच हो, किनकि इन्कोड गरिएको पाठले प्रतिनिधित्व गर्ने बाइटभन्दा लामो हुन्छ। त्यसपछि कुन पहिचान पङ्क्ति मिल्यो भनी पुष्टि गर्नुहोस्, किनकि गलत साथीमुनि राखिएको सही रहस्य गलतजस्तै असफल हुन्छ। पङ्क्तिको क्रमले यो निर्णय गर्छ: पहिलो मिलान जित्छ, त्यसैले माथितिरको फराकिलो %any पङ्क्तिले तपाईंले भर्खरै सम्पादन गरेको विशिष्ट पङ्क्तिलाई चुपचाप प्रतिस्थापन गर्छ।

फाइल सही भएपछि पुनः सुरु गर्नुको सट्टा पुनः लोड गर्नुहोस्। ipsec rereadsecrets IKE डेमनको प्रतिलिपि ताजा गर्छ, र swanctl सेटअपले आफ्नै आदेशद्वारा प्रमाणहरू लोड गर्छ। पुनः सुरु गर्दा स्थापित हरेक सम्बन्ध छोडिन्छ र तपाईंले गर्न खोजेको तुलना नष्ट हुन्छ।

यीमध्ये कुनै पनि जाँचले रहस्य खुलास गर्न माग गर्दैन। लम्बाइ, पहिचान चयनकर्ता र पङ्क्तिको स्थानले यस्ता अधिकांश असफलता व्याख्या गर्छ, कसैलाई हेक्स डम्प आवश्यक पर्नुअघि।

नतिजा नलुकाई फाइल परिवर्तन गर्नुहोस्

फाइललाई डेमनको खातामा सीमित राख्नुहोस्, र जीवित रहस्यहरू टिकट, च्याट र स्क्रिनसटबाट टाढा राख्नुहोस्, किनकि टाँसिएको कुञ्जी चुहावट हो, निदान होइन। यो आफूलाई बनाउने घटनाभन्दा पनि लामो बाँच्छ।

जसको कन्फिगरेसन तपाईंको नियन्त्रणमा छ त्यस्तो क्लाइन्टबाट परीक्षण गर्नुहोस्, प्रमाणीकरण सफल हुन्छ भनी पुष्टि गर्नुहोस्, र त्यसपछि सुरुङले ट्राफिक बोक्छ भनी पुष्टि गर्नुहोस्। जुन पुनः-लोडले ह्यान्डसेक सुधार्छ तर राउटिङ भाँचिएकै रहन्छ त्यो अर्को समस्या हो, र रहस्य सर्न छोड्ने बित्तिकै त्यो देखिन्छ।