एक IKEv2 लॉगिन में दो पहचानें: पहले मशीन, फिर उपयोगकर्ता

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

लक्षण: सफल पहले प्रमाण के बाद विफलता

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

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

एक्सटेंशन क्या जोड़ता है और क्या नहीं

IKEv2 एक ही सत्र के भीतर एक से अधिक प्रमाणीकरण आदान-प्रदान चलाने के लिए एक एक्सटेंशन रखता है। RFC 4739 अन्य क्रमों के साथ-साथ ऐसे क्लाइंट की रूपरेखा देता है जो प्रमाणपत्र पहचान सिद्ध करता है और फिर EAP के माध्यम से व्यक्ति का प्रमाणीकरण करता है। दस्तावेज़ Experimental है, यानी कोई कार्यान्वयन आपको यह सुविधा देने का ऋणी नहीं है। साथी पक्ष के इसे सहमत करने तक समर्थन के बारे में कुछ मत मानिए।

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

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

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

वही फ़ाइल गेटवे पर अलग तरह से पढ़ी जाती है

वही swanctl फ़ाइल इस पर निर्भर करती है कि वह कहाँ चलती है, और यही वह हिस्सा है जो लोगों को उलझाता है। लैपटॉप पर गेटवे साथी पक्ष है, और गेटवे पर लैपटॉप साथी पक्ष है, इसलिए local पक्ष को मैं कौन हूँ और remote पक्ष को मैं किसे स्वीकार करूँगा, ऐसे लिखें। local ब्लॉक बताता है कि यह एंडपॉइंट स्वयं को कैसे प्रमाणित करता है, और remote ब्लॉक बताता है कि वह दूसरे छोर से क्या माँगता है। दो फ़ाइलों के बीच ब्लॉक की नकल उसका अर्थ उलट देती है, एक भी अक्षर बदले बिना। दोनों फ़ाइलों की तुलना लगभग कुछ नहीं बताती, क्योंकि वही शब्द दोनों में विपरीत अर्थ रखते हैं।

किसी अनुभाग की स्थिति उसका क्रम तय करती है, जब तक राउंड संख्या उसे नहीं लाँघती। इसलिए अतिरिक्त local या remote अनुभाग विकल्पों के बजाय अतिरिक्त राउंड बताते हैं, और swanctl.conf संदर्भ में स्पष्ट राउंड संख्या ठीक इस क्रम को जानबूझकर बनाने के लिए है। इसके बिना ब्लॉक हिलाने से व्यवहार बदल जाता है। इसीलिए कागज़ पर समान दिखने वाली दो कॉन्फ़िगरेशन विपरीत क्रम में काम कर सकती हैं।

यह क्रम-नियम वह विफलता-विधि पैदा करता है जिसे याद रखना चाहिए। दूसरा remote ब्लॉक दूसरा स्वीकार्य विकल्प नहीं है, वह दूसरी माँग है, इसलिए जो नीति या/या जैसी पढ़ी जाती है वह और-फिर जैसी व्यवहार करती है। गेटवे नीति पंजीकृत मशीन का प्रमाणपत्र स्वीकार कर सकती है और फिर उस उपयोगकर्ता का EAP आदान-प्रदान उसी क्रम में माँग सकती है।

राउंड को स्वतंत्र कारकों से अलग पहचानें

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

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

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

युग्मन नियम लिखें और अस्वीकृतियाँ जाँचें

तय करें कि कौन-सी मशीन पहचानें किन लोगों के साथ युग्मित हो सकती हैं, और नियम वहाँ लिखें जहाँ प्रवर्तन रहता है। साथ-साथ रखे दो वैध क्रेडेंशियल युग्मन के बारे में कुछ सिद्ध नहीं करते, क्योंकि युग्मन प्रमाणीकरण का परिणाम नहीं बल्कि प्राधिकरण का निर्णय है। नामांकन अभिलेख या प्रमाणीकरण बैकएंड को वह संबंध लागू करना होगा जो संगठन चाहता है।

फिर वह जाँचें जो विफल होना चाहिए: अस्वीकृत मशीन पर स्वीकृत उपयोगकर्ता, मशीन का क्रेडेंशियल रखने वाला अस्वीकृत उपयोगकर्ता, और वह साथी पक्ष जो अतिरिक्त राउंड नहीं कर सकता। अगर तीनों को चुपचाप वही पहुँच मिल जाए, तो नीति लागू करने के बजाय मंशा बताती है। घोषित कॉन्फ़िगरेशन की तुलना डेमन के बताए से करें, क्योंकि जो कनेक्शन कभी मेल नहीं खाया वह पास हुए नियम जैसा ही दिखता है:

swanctl --list-conns
swanctl --list-sas

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