IKEv2 देवाणघेवाण काम करते, मग प्रमाणीकरण अयशस्वी होते: कुठे पाहावे

IKEv2 प्रतिसाद मिळणारा क्लायंट हे सिद्ध करतो की गेटवे पोहोचण्यायोग्य आहे, दोन्ही बाजू प्रस्तावावर बोलणी करू शकतात आणि सुरुवातीची की देवाणघेवाण पूर्ण झाली। पण कोणाचेही प्रमाणीकरण झाले आहे हे त्याने सिद्ध केले नाही। पुढील देवाणघेवाण ओळखी, प्रमाणपत्रे किंवा EAP वाहते, आणि सहसा कनेक्शन तिथेच थांबते। यापैकी कोणती तपासणी अयशस्वी झाली हे वाचणे हेच संपूर्ण निदान आहे, आणि केवळ त्रुटी संदेश हे क्वचितच सांगतो।

तपासणी 1: संदेश नाही, टप्पा वाचा

नाकारणे तीन ठिकाणांहून येऊ शकते: क्लायंट सर्व्हरची ओळख नाकारतो, गेटवे क्लायंटचा पुरावा नाकारतो आणि बाह्य प्रमाणीकरण सेवा खाते नाकारते।

प्रत्येक वेगळ्या मशीनवर वेगळी लॉग ओळ तयार करते, आणि प्रत्येकावर वेगळा उपाय आहे। क्लायंटच्या बाजूने सर्व्हर प्रमाणपत्र नाकारणे ही क्लायंटवरील विश्वास किंवा नामकरणाची समस्या आहे; गेटवेच्या बाजूने क्लायंट प्रमाणपत्र नाकारणे ही गेटवेवरील विश्वासाची समस्या आहे; EAP अपयश ही खाते किंवा बॅकएंडची समस्या आहे। तुम्हाला दिसणारा संदेश सहसा यापैकी एकाबद्दल क्लायंटचा सारांश असतो, म्हणूनच गेटवेचा लॉग क्लायंटच्या लॉगइतकाच महत्त्वाचा आहे।

तपासणी 2: कोणती ओळख तपासली गेली

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

strongSwanच्या संज्ञेत ते क्लायंटवरील rightid आणि दुसऱ्या बाजूला गेटवेची स्वतःची ओळख आहे, आणि EAP चर्चेपूर्वीच जुळणी नसल्यास अपयश येते।

गेटवे स्वतंत्रपणे क्लायंटचे प्रमाणपत्र, त्याचा की पुरावा किंवा त्याचे खाते प्रमाणीकरण नाकारू शकतो, आणि हे तीन परस्पर बदलण्यायोग्य नाहीत। वापरकर्त्याचा संकेतशब्द रीसेट करून उपकरणाचे प्रमाणपत्र नूतनीकरण होत नाही, आणि उपकरणाचे प्रमाणपत्र पुन्हा प्रस्थापित करून चुकीची सर्व्हर ओळख सुधारत नाही। प्रमाणपत्र अपयशांसाठी आधी घड्याळ, नंतर विश्वासाची साखळी, नंतर अपेक्षित ओळखकर्ता तपासा; काही मिनिटे चुकीचे घड्याळ असलेला क्लायंट विश्वासाच्या अपयशासारखे दिसणाऱ्या वैधता तपासणीत अपयशी ठरतो। swanctl --list-certs दोन्ही टोकांवर प्रत्येक बाजूकडे प्रत्यक्षात काय आहे ते दाखवते।

तपासणी 3: EAP सहभागी असल्यास

क्लायंट आणि सर्व्हरने समर्थित पद्धतीवर एकमत होणे आवश्यक आहे, आणि बॅकएंडने दिलेली ओळख स्वीकारणे आवश्यक आहे।

वापरकर्तानावाला डोमेन प्रत्यय किंवा तैनातीची आवश्यकता असलेले विशिष्ट खाते स्वरूप लागू शकते, आणि स्वरूप अंदाजाचे नसून दस्तऐवजीकृत आहे। ऑपरेटरची दस्तऐवजीकृत क्षेत्रे देणे प्रकारांच्या चाचणीपेक्षा वेगवान आहे, आणि दुसरी समस्या टाळते: वारंवार प्रयत्नांमुळे खाते लॉकआउट होऊ शकते, जे नंतर मूळ टप्पा नवीन अपयशामागे लपवते। पद्धत डिरेक्टरीविरुद्ध EAP-MSCHAPv2 असल्यास, अपयश VPNचे नसून डिरेक्टरीचे असू शकते।

ओळख तपासण्या बंद करून ओळखीच्या समस्या तपासू नका। त्यामुळे निदान करण्यायोग्य अपयश निदान न करण्यायोग्य होते आणि कनेक्शन पूर्वीपेक्षा कमकुवत राहते।

तपासणी 4: यशस्वी लॉगिननंतर काय होते

IKE_AUTH पूर्ण झाल्यावर, कोणते रहदारी निवडक स्थापित करायचे हे CHILD_SA वाटाघाटी ठरवते, आणि तिथेच कनेक्शन यशस्वी होऊनही काहीही पास होऊ शकत नाही।

नव्याने कार्यरत लॉगिन अनेकदा पूर्वी प्रमाणीकरण अपयशामागे लपलेली निवडक किंवा मार्गाची समस्या उघड करते। बोगदा वर आला तरी अनुप्रयोग आपल्या गंतव्यापर्यंत पोहोचत नसेल, तर पुन्हा ओळखीकडे नाही, वाटाघाटी झालेल्या निवडकांकडे आणि मार्गांकडे पाहा। त्या क्षणी ओळख सेटिंग्ज बदलणे चुकीच्या टप्प्याला लक्ष्य करते आणि सहसा कार्यरत लॉगिन तोडते। swanctl --list-sas ने पुष्टी करा, जे IKE SAपासून वेगळे चाइल्ड आणि त्यांचे निवडक दाखवते।

तपासणी 5: सपोर्टला काय द्यावे

स्वच्छ केलेली समयरेषा आणि अचूक नाकारणे पूर्ण निदान निर्यातीपेक्षा अधिक मूल्यवान आहेत, आणि निर्यातीत सामायिक न करावयाच्या खाजगी की किंवा क्रेडेन्शियल असू शकतात।

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