EAP या क्लाइंट प्रमाणपत्र? IKEv2 प्रमाणीकरण तय करना

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

किसी भी वस्तु को छूने से पहले तय करें कि कौन-सा दावा विफल हुआ। विफलता का चरण आपको यह बताता है, अगर आप क्रम से पढ़ें।

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

सर्वर प्रमाणपत्र एक नाम को कुंजी से बांधता है, और क्लाइंट उस बंधन को अपने ट्रस्ट स्टोर के विरुद्ध जांचता है। क्लाइंट प्रमाणपत्र एक पहचान को कुंजी से बांधता है, और गेटवे जांचता है कि प्रस्तुत प्रमाणपत्र किसी ऐसी चीज़ तक श्रृंखलाबद्ध है जिस पर उसे भरोसा है। EAP प्रमाणीकरण का आदान-प्रदान ले जाता है जिसकी सामग्री चुनी गई विधि पर निर्भर करती है। ये तीन संरचनाएं हैं जिनका जीवनकाल, स्वामी और विफलता के तरीके अलग हैं।

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

EAP एक पात्र है, विधि नहीं

EAP एक ढांचा है: गेटवे और क्लाइंट एक विधि पर बातचीत करते हैं, और विधि तय करती है कि पासवर्ड, टोकन, सुरंग के भीतर का आंतरिक आदान-प्रदान या प्रमाणपत्र शामिल है, जैसा कि IKEv2 पर strongSwan दस्तावेज़ बताता है। इसीलिए EAP-TLS क्लाइंट की ओर से EAP-MSCHAPv2 जैसा बिल्कुल नहीं दिखता, भले ही दोनों मेनू में EAP के रूप में दिखते हैं। केवल EAP बताने वाली प्रोफ़ाइल ने आपको यह नहीं बताया कि उपयोगकर्ता से क्या पूछा जाएगा।

विधि और बैकएंड को साथ पढ़ें। बैकएंड खाता प्रारूप, लॉकआउट व्यवहार और यह तय करता है कि पासवर्ड रीसेट वास्तव में क्या बदलता है, और इसमें से कुछ भी क्लाइंट प्रोफ़ाइल में दिखाई नहीं देता।

मिश्रित परिनियोजन सामान्य है

उपयोगकर्ता के लिए सर्वर प्रमाणपत्र के साथ EAP वह स्वरूप है जो अधिकांश दूरस्थ-पहुंच गेटवे परिनियोजित करते हैं, क्योंकि यह क्लाइंट को सत्यापन-योग्य एंडपॉइंट और ऑपरेटर को केंद्रीय खाता भंडार में प्रति-उपयोगकर्ता पहचान देता है। क्लाइंट प्रमाणपत्र वाले परिनियोजन भी मौजूद हैं, आमतौर पर जहां डिवाइस की पहचान पासवर्ड से अधिक मायने रखती है। दोनों वैध हैं, और गलती यह मान लेना है कि पिछले हफ़्ते जो देखा वही आपके सामने है।

क्लाइंट में फ़ील्ड नामों से अनुमान लगाने के बजाय ऑपरेटर से प्रलेखित विधि और खाता प्रारूप मांगें।

विफलता के चरण से निर्णय

अवलोकनों को क्रम में रखें। किसी भी उपयोगकर्ता संकेत से पहले आने वाली ट्रस्ट त्रुटि सर्वर-प्रमाणपत्र की समस्या है और कोई पासवर्ड उसे ठीक नहीं करेगा। संकेत के बाद अस्वीकृति आना उपयोगकर्ता-प्रमाणीकरण की समस्या है, जिसमें EAP विधि और बैकएंड संदिग्ध हैं। सफल प्रमाणीकरण के बाद child-SA विफलता इन दोनों में से कोई नहीं है।

दो और भेद मायने रखते हैं। सर्वर प्रमाणपत्र अस्वीकार करने वाला क्लाइंट आमतौर पर नाम में असंगति या अज्ञात प्राधिकरण की सूचना देता है, जो ट्रस्ट-स्टोर का सवाल है। उपयोगकर्ता को अस्वीकार करने वाला गेटवे अक्सर EAP विधि और कारण श्रेणी दर्ज करता है, जो खाते या नीति का सवाल है।

दोनों मॉडल चलाना

प्रमाणपत्रों में काम है जारी करना, नवीनीकरण, निरस्तीकरण और खोए डिवाइस हटाना, और यह आपके नियंत्रित समय-सारणी पर होता है। EAP में काम है खाता जीवनचक्र, हर क्लाइंट प्लेटफ़ॉर्म पर विधि समर्थन और बैकएंड जो भी दूसरा कारक मांगे। कोई मॉडल अमूर्त रूप से सस्ता नहीं है; वे अलग-अलग टीमों पर भार डालते हैं। लिख लें कि आपका परिनियोजन वास्तव में कौन-सा उपयोग करता है, क्योंकि सहायता स्क्रिप्ट कॉन्फ़िगरेशन से अधिक भिन्न होती हैं।

उन्हें अपने नोट्स में अलग रखें। प्रमाणपत्र की समाप्ति किसी तारीख पर विफलता पैदा करती है, खाता लॉकआउट पासवर्ड बदलने के बाद विफलता पैदा करता है, और विधि में असंगति केवल एक प्लेटफ़ॉर्म पर विफलता पैदा करती है।

पहचान स्वीकार होने के बाद

प्रमाणीकरण एक द्वार है। child सुरक्षा संबंध, ट्रैफ़िक चयनकर्ता, DNS और अनुप्रयोग की अपनी अनुमतियां बाद के द्वार हैं, और हर एक अपनी शर्तों पर विफल होता है। स्वीकृत पहचान जो कहीं नहीं पहुंचती वह प्रमाणीकरण की समस्या नहीं है।

विधि, प्रयुक्त खाता या प्रमाणपत्र और विफल हुआ चरण दर्ज करें। वह नोट अगली घटना को प्रयोग के बजाय खोज में बदल देता है।