EAP की क्लायंट प्रमाणपत्रे? IKEv2 प्रमाणीकरण ठरवणे

तुमचा गेटवे स्वतःची ओळख प्रमाणपत्राने सिद्ध करू शकतो आणि तुमची ओळख EAP द्वारे, आणि हे संयोजन विरोधाभासी नसून सामान्य आहे. दोन्ही यंत्रणा वेगवेगळ्या प्रश्नांची उत्तरे देतात: हा टोक मी अपेक्षित असलेलाच आहे का, आणि या वापरकर्त्याला किंवा उपकरणाला परवानगी आहे का. प्रोफाइलमध्ये EAP दिसणे सर्व्हर पडताळणी बंद करत नाही. प्रोफाइल एकच सेटिंग म्हणून वाचणे हेच लोकांना चुकीचे क्रेडेन्शियल रीसेट करायला पाठवते.

दोन्हीपैकी कोणत्याही वस्तूला स्पर्श करण्यापूर्वी कोणता दावा अयशस्वी झाला ते ठरवा. अयशस्वीतेचा टप्पा ते सांगेल, क्रमाने वाचल्यास.

दोन क्रेडेन्शियल, दोन दावे

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

खाजगी की उघडणारा पासफ्रेज खाते पासवर्ड नाही, दोन्ही प्रॉम्प्ट एकमेकांपासून सेकंदांत दिसले तरीही. एक उपकरणाच्या की स्टोअरमध्ये स्थानिक आहे, आणि दुसरे गेटवेच्या मागील प्रमाणीकरण सर्व्हर पडताळतो.

EAP एक पात्र आहे, पद्धत नाही

EAP एक चौकट आहे: गेटवे आणि क्लायंट पद्धतीवर बोलणी करतात, आणि पद्धत ठरवते की पासवर्ड, टोकन, बोगद्यातील अंतर्गत देवाणघेवाण की प्रमाणपत्र सहभागी आहे, IKEv2 वरील strongSwan दस्तऐवज स्पष्ट करतो त्याप्रमाणे. म्हणूनच EAP-TLS क्लायंटच्या बाजूने EAP-MSCHAPv2 सारखे अजिबात दिसत नाही, दोन्ही मेनूमध्ये EAP म्हणून दिसले तरी. फक्त EAP असे सांगणारे प्रोफाइल वापरकर्त्याला काय विचारले जाईल हे तुम्हाला सांगत नाही.

पद्धत आणि बॅकएंड एकत्र वाचा. बॅकएंड खाते स्वरूप, लॉकआउट वर्तन आणि पासवर्ड रीसेट प्रत्यक्षात काय बदलते हे ठरवते, आणि त्यातील काहीही क्लायंट प्रोफाइलमध्ये दिसत नाही.

मिश्र तैनाती सामान्य आहे

वापरकर्त्यासाठी सर्व्हर प्रमाणपत्र आणि EAP हे जे स्वरूप बहुतेक दूरस्थ प्रवेश गेटवे तैनात करतात, कारण ते क्लायंटला पडताळण्यायोग्य टोक आणि ऑपरेटरला केंद्रीय खाते संग्रहात प्रत्येक वापरकर्त्याची ओळख देते. क्लायंट प्रमाणपत्रांसह तैनातीही आहेत, सामान्यतः जिथे उपकरणाची ओळख पासवर्डपेक्षा महत्त्वाची असते. दोन्ही वैध आहेत, आणि गेल्या आठवड्यात जे पाहिले तेच समोर आहे असे गृहीत धरणे ही चूक आहे.

क्लायंटमधील फील्ड नावांवरून अंदाज न लावता ऑपरेटरकडे दस्तऐवजीकृत पद्धत आणि खाते स्वरूप विचारा.

अयशस्वीतेच्या टप्प्यावरून निर्णय

निरीक्षणे क्रमाने लावा. कोणत्याही वापरकर्ता प्रॉम्प्टपूर्वीची विश्वास त्रुटी सर्व्हर-प्रमाणपत्राची समस्या आहे आणि कोणताही पासवर्ड ती दुरुस्त करणार नाही. प्रॉम्प्टनंतर नकार आला तर ती वापरकर्ता-प्रमाणीकरणाची समस्या आहे, EAP पद्धत आणि बॅकएंड संशयित असून. यशस्वी प्रमाणीकरणानंतर child-SA अयशस्वी झाले तर ते दोन्हीपैकी काहीही नाही.

अजून दोन फरक महत्त्वाचे आहेत. सर्व्हर प्रमाणपत्र नाकारणारा क्लायंट सामान्यतः नावाची विसंगती किंवा अज्ञात प्राधिकरण नोंदवतो, जो विश्वास-संग्रहाचा प्रश्न आहे. वापरकर्त्याला नाकारणारा गेटवे अनेकदा EAP पद्धत आणि कारण श्रेणी नोंदवतो, जो खाते किंवा धोरणाचा प्रश्न आहे.

दोन्ही मॉडेल चालवणे

प्रमाणपत्रांमध्ये काम म्हणजे जारी करणे, नूतनीकरण, रद्द करणे आणि हरवलेली उपकरणे काढणे, आणि ते तुम्ही नियंत्रित करता त्या वेळापत्रकानुसार होते. EAP मध्ये काम म्हणजे खाते जीवनचक्र, प्रत्येक क्लायंट प्लॅटफॉर्मवर पद्धत समर्थन आणि बॅकएंड मागणारा कोणताही दुसरा घटक. कोणतेही मॉडेल अमूर्तपणे स्वस्त नाही; ते वेगवेगळ्या संघांवर भार टाकतात. तुमची तैनाती प्रत्यक्षात कोणते वापरते ते लिहा, कारण समर्थन स्क्रिप्ट संरचनेपेक्षा जास्त वेगळ्या आहेत.

त्या तुमच्या नोट्समध्ये वेगळ्या ठेवा. प्रमाणपत्राची मुदत संपणे ठराविक तारखेला अयशस्वीता निर्माण करते, खाते लॉकआउट पासवर्ड बदलल्यानंतर अयशस्वीता निर्माण करते, आणि पद्धतीची विसंगती फक्त एका प्लॅटफॉर्मवर अयशस्वीता निर्माण करते.

ओळख स्वीकारल्यानंतर

प्रमाणीकरण एक दरवाजा आहे. child सुरक्षा संघटन, ट्रॅफिक निवडक, DNS आणि अनुप्रयोगाच्या स्वतःच्या परवानग्या नंतरचे दरवाजे आहेत, आणि प्रत्येक स्वतःच्या अटींवर अयशस्वी होतो. कुठेही न पोहोचणारी स्वीकारलेली ओळख प्रमाणीकरणाची समस्या नाही.

पद्धत, वापरलेले खाते किंवा प्रमाणपत्र आणि अयशस्वी झालेला टप्पा नोंदवा. ती नोंद पुढील घटनेला प्रयोगाऐवजी शोधात बदलते.