IKE में MAC का मेल न खाना यानी साझा कुंजी की जाँच विफल हुई

आपका Cloud VPN लॉग साझा कुंजी के प्रयास के बाद MAC mismatched दिखाता है, और पहली प्रवृत्ति अक्सर पते की समस्या खोजना होती है। इस शाखा में MAC संदेश प्रमाणीकरण कोड है: बातचीत की गई कुंजी के साथ विनिमय पर गणना किया गया मान। साथी ने अपनी गणना की तुलना प्राप्त मान से की, और वे भिन्न थे। इसमें कोई नेटवर्क कार्ड शामिल नहीं है, और कोई इंटरफ़ेस सेटिंग उस तुलना को नहीं बदलती।

व्यवहार में दो स्थितियाँ इसे उत्पन्न करती हैं: दोनों सिरों के रहस्य एक ही मान नहीं हैं, या रहस्य चुनने के लिए उपयोग की जाने वाली पहचानें मेल नहीं खातीं। जोड़ी पढ़कर तय करें कौन-सी, अकेली सुरंग नहीं।

यह चरण क्या सिद्ध करता है

जाँच तब चलती है जब दोनों पक्ष प्रारंभिक पैरामीटर बदल चुके होते हैं और खुद को पहचान चुके होते हैं। यह स्थानीय और दूरस्थ पहचानों के लिए उम्मीदवार साझा कुंजियाँ चुनती है और प्राप्त प्रमाणीकरण डेटा को मान्य करने का प्रयास करती है; जब कोई भी मान्य न हो, निदान जारी होता है। यह प्रमाणीकरण के बारे में मज़बूत और कारण के बारे में कमज़ोर कथन है, क्योंकि यह नहीं बताता कि कौन-सा पक्ष गलत है।

पहले की सफलता इस जाँच में नहीं आती। पूर्ण IKE_SA_INIT, या अपेक्षित मान लौटाने वाला NAT पहचान पेलोड, सिद्ध करता है कि साथी बात कर सकते हैं। यह इस बारे में कुछ भी सिद्ध नहीं करता कि वे रहस्य साझा करते हैं या नहीं।

दो कॉन्फ़िगरेशन त्रुटियाँ, एक संदेश

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

किसी भी रहस्य को छूने से पहले जोड़ी की तुलना करें। सुरंग, साथी का अंतिम बिंदु, समय विंडो और दूरस्थ कॉन्फ़िगरेशन मिलाएँ, क्योंकि दो अतिरिक्त सुरंगों में अलग-अलग रहस्य हो सकते हैं और आपके सामने की स्क्रीन वह न हो जो विफल हुई।

NAT पहचान एक अलग चरण है

NAT पहचान पूछती है कि पैकेट कैसे फिर से लिखे जाते हैं, यह नहीं कि साथी कौन है। NAT के पीछे का ग्राहक गेटवे तब भी सही प्रमाणीकरण करता है जब उसकी कॉन्फ़िगर की गई पहचान वही हो जिसकी साथी अपेक्षा करता है, और NAT समस्या प्रमाणीकरण तुलना की विफलता के बजाय प्रस्ताव या पोर्ट की असंगति के रूप में दिखती है।

एक विक्रेता रिलीज़ के बारे में पुराना कथन वर्तमान परिनियोजन में न ले जाएँ। आपकी रिलीज़ में NAT ट्रैवर्सल को क्या चाहिए, वह उसी के दस्तावेज़ में आता है, और MAC mismatch वाक्यांश इसके पक्ष या विपक्ष में प्रमाण नहीं है।

स्क्रीन नहीं, जोड़ी से तय करें

रहस्य छिपाकर दोनों कॉन्फ़िगरेशन साथ-साथ पढ़ें, फिर तीन प्रश्न पूछें। क्या हर पक्ष की पहचान ठीक वही है जिसकी दूसरा पक्ष अपेक्षा करता है, अक्षर दर अक्षर? क्या दोनों सिरे एक ही IKE संस्करण और एक ही प्रमाणीकरण विधि का उपयोग कर रहे हैं? क्या विफल सुरंग उस कॉन्फ़िगरेशन से मेल खाती है जो आप पढ़ रहे हैं? इनमें से किसी पर भी 'नहीं' रहस्य छुए बिना मरम्मत तय कर देता है।

यदि तीनों साफ़ हों, तो उसके चारों ओर संपादन करने के बजाय स्वीकृत कार्यप्रवाह से रहस्य बदलें।

साथी के प्रमाणीकरण के बाद

प्रमाणीकरण सफल होते ही अगली विफलता सतह चाइल्ड सुरक्षा संगठन है: प्रस्ताव और ट्रैफ़िक चयनकर्ता। पहले से स्वीकृत रहस्य घुमाना चाइल्ड विफलता ठीक नहीं कर सकता, और यह रुकावट को लंबा करता है। चाइल्ड स्थिति पढ़ें, फिर दोनों पक्षों के चयनकर्ता और संरक्षित श्रेणियाँ, और Cloud VPN समस्या-निवारण मार्गदर्शन को उस चरण से मिलाएँ जो वास्तव में विफल हुआ।

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

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

संदेश को MAC पते बदलने की मांग के रूप में न पढ़ें, और मदद माँगते समय साझा रहस्य प्रकाशित न करें; कुंजी वाले अंश से कुंजी हटाई जानी चाहिए, लॉग रखा नहीं। रूटिंग खराबी भी न मानें, क्योंकि जो साथी एक-दूसरे तक नहीं पहुँच सकते वे कोई प्रमाणीकरण तुलना पैदा ही नहीं करते। और एक उत्पाद परिवार की प्रलेखित सीमा को हर IPsec कार्यान्वयन तक सामान्यीकृत न करें।

विफल जोड़ी, टनल की स्थिति पहले और बाद में, और दो स्थितियों में से कौन-सी बदली, यह दर्ज करें। वह रिकॉर्ड अगली घटना को पाँच मिनट की जाँच बना देता है।