IKE मध्ये MAC जुळत नाही म्हणजे सामायिक किल्लीची तपासणी अयशस्वी झाली

तुमचा Cloud VPN लॉग सामायिक किल्लीचा प्रयत्न आणि त्यानंतर MAC mismatched दाखवतो, आणि पहिली प्रवृत्ती बऱ्याचदा पत्त्याची समस्या शोधणे असते। या शाखेत MAC हा संदेश प्रमाणीकरण कोड आहे: वाटाघाटी केलेल्या किल्लीसह देवाणघेवाणीवर गणना केलेले मूल्य। सहकारीाने आपली गणना मिळालेल्या मूल्याशी तुलना केली, आणि ती वेगळी होती। येथे कोणतेही नेटवर्क कार्ड सहभागी नाही, आणि कोणतेही इंटरफेस सेटिंग ती तुलना बदलत नाही।

प्रत्यक्षात दोन अटी ती निर्माण करतात: दोन्ही टोकांची रहस्ये एकच मूल्य नाहीत, किंवा रहस्य निवडण्यासाठी वापरली जाणारी ओळख जुळत नाही। जोडी वाचून कोणती ते ठरवा, एकटी सुरंग नाही।

टप्पा काय सिद्ध करतो

दोन्ही बाजूंनी प्रारंभिक मापदंडांची देवाणघेवाण करून स्वतःची ओळख दिल्यानंतर तपासणी चालते। ती स्थानिक आणि दूरच्या ओळखींसाठी उमेदवार सामायिक किल्ल्या निवडते आणि मिळालेला प्रमाणीकरण डेटा वैध करण्याचा प्रयत्न करते; कोणताही वैध न झाल्यास निदान जारी होते। हे प्रमाणीकरणाबद्दल मजबूत आणि कारणाबद्दल कमकुवत विधान आहे, कारण कोणती बाजू चुकीची आहे ते सांगत नाही।

पूर्वीचे यश या तपासणीत येत नाही। पूर्ण झालेला IKE_SA_INIT, किंवा अपेक्षित मूल्ये परत करणारा NAT शोध पेलोड, सहकारी बोलू शकतात हे सिद्ध करतो। ते रहस्य सामायिक करतात का याबद्दल काहीही सिद्ध करत नाही।

दोन कॉन्फिगरेशन त्रुटी, एक संदेश

पहिली खरी रहस्य असंगती आहे, आणि सहसा ती प्रोव्हिजनिंग अपघात असते: एका कन्सोलवर स्थापित आणि दुसऱ्यावर पुन्हा टाइप केलेले व्युत्पन्न मूल्य, एका बाजूला टिकून राहिलेले शेवटचे अक्षर, किंवा पेस्टसोबत आलेले अवतरण चिन्ह। दुसरी ओळखीची असंगती आहे, जिथे रहस्य बरोबर आहे पण सहकारी जी ओळख सादर करतो ती दुसरी नोंद निवडते, त्यामुळे बरोबर रहस्य कधीही वापरले जात नाही। दोन्ही एकच ओळ देतात, म्हणून अंदाज लावण्यास एक दुपार जाते।

कोणतेही रहस्य स्पर्श करण्यापूर्वी जोडीची तुलना करा। सुरंग, सहकाऱ्याचा शेवटचा बिंदू, वेळ विंडो आणि दूरचे कॉन्फिगरेशन जुळवा, कारण दोन अतिरिक्त सुरुंगांमध्ये वेगळी रहस्ये असू शकतात आणि तुमच्यासमोरील स्क्रीन अयशस्वी झालेली नसेल।

NAT शोध हा वेगळा टप्पा आहे

NAT शोध विचारतो की पॅकेट कसे पुन्हा लिहिले जातात, सहकारी कोण आहे हे नाही। NAT मागील ग्राहक गेटवे जेव्हा त्याची कॉन्फिगर केलेली ओळख सहकाऱ्याच्या अपेक्षेप्रमाणे असते तेव्हाही योग्य प्रमाणीकरण करतो, आणि NAT समस्या प्रमाणीकरण तुलनेच्या अपयशाऐवजी प्रस्ताव किंवा पोर्टची असंगती म्हणून दिसते।

एका विक्रेता आवृत्तीबद्दलचे जुने विधान सध्याच्या तैनातीत आणू नका। तुमच्या आवृत्तीत NAT प्रवासाला काय आवश्यक आहे ते त्याच्या स्वतःच्या दस्तऐवजात येते, आणि MAC mismatch हा वाक्प्रचार त्याच्या बाजूने किंवा विरुद्ध पुरावा नाही।

स्क्रीनवरून नाही, जोडीवरून ठरवा

रहस्य झाकून दोन्ही कॉन्फिगरेशन शेजारी शेजारी वाचा, नंतर तीन प्रश्न विचारा। प्रत्येक बाजूची ओळख दुसऱ्याच्या अपेक्षेप्रमाणे अक्षरशः आहे का? दोन्ही टोके एकच IKE आवृत्ती आणि एकच प्रमाणीकरण पद्धत वापरतात का? अयशस्वी सुरंग तुम्ही वाचत असलेल्या कॉन्फिगरेशनशी जुळते का? यापैकी कोणत्याही गोष्टीला 'नाही' असल्यास रहस्याला स्पर्श न करता दुरुस्ती ठरते।

तिन्ही स्वच्छ असल्यास, आजूबाजूला संपादन करण्याऐवजी मंजूर कार्यप्रवाहातून रहस्य बदला।

सहकारी प्रमाणीकृत झाल्यानंतर

प्रमाणीकरण यशस्वी झाल्यावर पुढील अपयश पृष्ठभाग चाइल्ड सुरक्षा संघटना आहे: प्रस्ताव आणि रहदारी निवडक। आधीच स्वीकारलेले रहस्य फिरवल्याने चाइल्ड अपयश सुटत नाही, आणि ते व्यत्यय लांबवते। चाइल्ड स्थिती, नंतर दोन्ही बाजूंचे निवडक आणि संरक्षित श्रेणी वाचा, आणि Cloud VPN समस्या निवारण मार्गदर्शन प्रत्यक्षात अयशस्वी झालेल्या टप्प्याशी जुळवा।

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

काय निष्कर्ष काढू नये

संदेशाला MAC पत्ते बदलण्याची मागणी म्हणून वाचू नका, आणि मदत मागताना सामायिक रहस्य प्रकाशित करू नका; किल्ली असलेल्या उताऱ्यातून किल्ली काढली पाहिजे, लॉग ठेवू नये। राउटिंग दोषही गृहीत धरू नका, कारण एकमेकांपर्यंत पोहोचू न शकणारे सहकारी कोणतीही प्रमाणीकरण तुलना निर्माण करत नाहीत। आणि एका उत्पादन कुटुंबाची दस्तऐवजी मर्यादा प्रत्येक IPsec अंमलबजावणीवर सामान्यीकृत करू नका।

अयशस्वी जोडी, आधी आणि नंतरची सुरंग स्थिती, आणि दोन अटींपैकी कोणती बदलली ते नोंदवा। ती नोंद पुढील घटनेला पाच मिनिटांची तपासणी बनवते।