IKE मा MAC नमिल्नु भनेको साझा कुञ्जीको जाँच असफल भयो

तपाईंको Cloud VPN लगले साझा कुञ्जीको प्रयास र त्यसपछि MAC mismatched देखाउँछ, र पहिलो प्रवृत्ति प्रायः ठेगानाको समस्या खोज्नु हुन्छ। यस शाखामा MAC सन्देश प्रमाणीकरण कोड हो: वार्ता गरिएको कुञ्जीसँगको आदानप्रदानमा गणना गरिएको मान। सहकर्मीले आफ्नो गणना प्राप्त मानसँग तुलना गर्यो, र ती फरक थिए। यहाँ कुनै नेटवर्क कार्ड संलग्न छैन, र कुनै इन्टरफेस सेटिङले त्यो तुलना बदल्दैन।

व्यवहारमा दुई सर्तले यो उत्पन्न गर्छन्: दुई छेउका रहस्यहरू एउटै मान होइनन्, वा रहस्य छान्न प्रयोग हुने पहिचानहरू मिल्दैनन्। जोडी पढेर कुन हो ठिक गर्नुहोस्, एकल सुरुङ होइन।

यो चरणले के प्रमाणित गर्छ

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

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

दुई कन्फिगरेसन त्रुटि, एउटा सन्देश

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

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

NAT पत्ता लगाउने अर्को चरण हो

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

एक विक्रेता रिलिजबारे पुरानो भनाइ वर्तमान डिप्लोयमेन्टमा नल्याउनुहोस्। तपाईंको रिलिजमा NAT यात्राले के चाहन्छ त्यो यसकै दस्तावेजमा पर्छ, र MAC mismatch वाक्यांश यसको पक्ष वा विपक्षमा प्रमाण होइन।

स्क्रिनबाट होइन, जोडीबाट निर्णय गर्नुहोस्

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

तीनै सफा भए, वरिपरि सम्पादन गर्नुको सट्टा स्वीकृत कार्यप्रवाहबाट रहस्य बदल्नुहोस्।

सहकर्मी प्रमाणीकृत भएपछि

प्रमाणीकरण सफल भएपछि अर्को असफलता सतह चाइल्ड सुरक्षा संघ हो: प्रस्ताव र ट्राफिक चयनकर्ता। पहिले नै स्वीकारिएको रहस्य घुमाउँदा चाइल्ड असफलता सुधारिँदैन, र यसले अवरोध लम्ब्याउँछ। चाइल्ड स्थिति, त्यसपछि दुवै पक्षका चयनकर्ता र संरक्षित दायरा पढ्नुहोस्, र Cloud VPN समस्या समाधान मार्गदर्शनलाई वास्तवमा असफल भएको चरणसँग मिलाउनुहोस्।

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

के निष्कर्ष ननिकाल्ने

सन्देशलाई MAC ठेगाना बदल्ने मागका रूपमा नपढ्नुहोस्, र मद्दत माग्दा साझा रहस्य प्रकाशित नगर्नुहोस्; कुञ्जी भएको अंशबाट कुञ्जी हटाउनुपर्छ, लग राख्नु होइन। राउटिङ खराबी पनि नमान्नुहोस्, किनकि एकअर्कासम्म पुग्न नसक्ने सहकर्मीहरूले कुनै पनि प्रमाणीकरण तुलना उत्पन्न गर्दैनन्। र एउटा उत्पादन परिवारको दस्तावेजी सीमालाई प्रत्येक IPsec कार्यान्वयनमा सामान्यीकरण नगर्नुहोस्।

असफल जोडी, अघि र पछिको सुरुङ स्थिति, र दुई सर्तमध्ये कुन बदलियो नोट गर्नुहोस्। त्यो अभिलेखले अर्को घटनालाई पाँच मिनेटको जाँच बनाउँछ।