एउटै 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 सेटिङतिर नलाग्नुहोस्: जडान सफल नहुँदासम्म आवश्यक राउन्ड मेटाउनुको सट्टा प्रोटोकल, भूमिका, क्रम र क्लाइन्टको वास्तविक व्यवहार मिलाउनुहोस्। असफल हुने राउन्ड मेटाउनु भनेको दुई-प्रमाणको डिजाइन कसैले पुनरावलोकन नगरेको एक-प्रमाणको डिजाइनमा चुपचाप बदलिने बाटो हो। मेटाइलाई परिवर्तन-अभिलेखमा राख्नुहोस्।