OpenVPN प्याकेट HMAC प्रमाणीकरण असफल: कुन तह?

दुई असफलता एउटै शब्दावलीमा रिपोर्ट गरिन्छ र तिनीहरूमा लगभग केही पनि साझा छैन। एउटा त्यो प्याकेट हो जसको प्रमाणीकरण ट्याग प्रमाणित भएन; अर्को त्यो व्यक्ति हो जसको प्रमाणहरू अस्वीकार गरियो। पहिलोलाई दोस्रो मान्दा तपाईं कहिल्यै समस्या नभएको पासवर्डको खोजीमा जानुहुन्छ।

सन्देशले एउटा तहको नाम लिन्छ, र उपयोगी काम भनेको कुनै पनि सामग्री बदल्नु अघि कुन तह हो भनेर निर्णय गर्नु हो। उम्मेदवारहरूलाई छेउछाउ राखेर तुलना गर्नु फरक देख्ने सबैभन्दा छिटो तरिका हो।

एउटै शब्द साझा गर्ने दुई असफलता

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

यो भिन्नताले मर्मत बदल्छ। एउटालाई च्यानल सेटिङ मिलाउनु आवश्यक छ, अर्कोलाई खाताको अवस्था, र तेस्रोलाई पुगेको स्रोतासँग नमिल्ने प्रोफाइल।

चलिरहेको प्रक्रियाले वास्तवमा के लोड गरेको हो त्यो तुलना गर्नुहोस्

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

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

नियन्त्रण च्यानलको डेटा च्यानलसँग तुलना गर्नुहोस्

दुई संयन्त्रले जडानका फरक भागहरू प्रमाणित गर्छन् र छुट्टै कन्फिगर हुन्छन्, जसरी 2.6 विकल्प सन्दर्भ वर्णन गर्छ। tls-auth नियन्त्रण-च्यानल प्याकेटमा HMAC थप्छ र दुई पियरमा विपरीत हुनुपर्ने दिशा-तर्क लिन्छ, जबकि tls-crypt त्यसको सट्टा नियन्त्रण च्यानललाई साझा कुञ्जीले सुरक्षित गर्छ। दुवैमध्ये कुनै पनि डेटा च्यानलको आफ्नै अखण्डता जाँच होइन। AEAD डेटा साइफरसँग त्यो जाँच साइफरमै निर्मित हुन्छ, त्यसैले auth अलग डाइजेस्ट AEAD नभएको साइफरजस्तै प्रयोग गरिँदैन।

अर्थात्, काम गरिरहेको AEAD नभएको डिप्लोयमेन्टबाट प्रतिलिपि गरिएको auth लाइन AEAD डिप्लोयमेन्टमा अप्रासंगिक हुन सक्छ, र AEAD डिप्लोयमेन्ट नियन्त्रण च्यानलमा अझै असफल हुन सक्छ, यदि tls-auth कुञ्जी वा त्यसको दिशा गलत छ भने। प्रत्येक सेटिङको तुलना पियरसँग गर्नुहोस्, सम्झिएको कन्फिगरेसनसँग होइन।

मर्मतको तुलना तपाईंले त्याग्ने गुणसँग गर्नुहोस्

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

केही पनि बदल्नु अघि दुवै छेउमा पहिलो सान्दर्भिक घटना पढ्नुहोस्, त्यसपछि त्यसले नाम लिएको बेमेल मात्र बदल्नुहोस्।

यदि अर्को प्रयास प्रमाणपत्र वा लगइन त्रुटिसम्म पुग्छ भने त्यो अवनति होइन, प्रगति हो: प्याकेट तह अब सहमत छ र जडान अगाडि बढेको छ। परिवर्तन ल्याउने सेटिङहरू लेख्नुहोस्, ताकि अर्को व्यक्तिले पहेलीको सट्टा व्याख्या उत्तराधिकारमा पाओस्।