IKEv2 सर्भर ठेगाना बनाम पहिचान: ग्राहकले वास्तवमा के जाँच गर्छ

ठेगाना परिवर्तन गर्ने गेटवेले काम गरिरहन सक्छ जब नयाँ प्रमाणपत्र पछाडि उही गेटवे रोकिन्छ, र उल्टो पनि हुन्छ। ठेगानाले ग्राहकलाई प्याकेटहरू कहाँ पठाउने भनेर बताउँछ; प्रमाणिकरण पहिचानले ग्राहकलाई बताउँछ कि सहकर्मी जवाफ दिने उसले विश्वास गर्नुपर्छ। IKEv2 ले तिनीहरूलाई दुई अलग क्षेत्रको रूपमा राख्छ, जुन उपयोगी हुन्छ एकपटक तपाईंले तिनीहरूलाई एउटै स्ट्रिङको रूपमा व्यवहार गर्न बन्द गर्नुभयो। तिनीहरू पनि विभिन्न ठाउँहरूमा कन्फिगर गरिएका छन्, त्यसैले एउटा सही हुन सक्छ जबकि अर्को गलत छ।

तिनीहरूलाई यस क्रममा जाँच गर्नुहोस् र पहिलो बेमेलमा रोक्नुहोस्, किनभने पछिको जाँचहरूले पहिलेको पास भएको मान्दछ।

पहिलो, कुन मान ठेगाना हो

जडान ठेगाना जुनसुकै ग्राहकले डायल गर्छ: एक आईपी, एउटा DNS नाम जसले समाधान गर्छ, वा लोड-सन्तुलित फ्रन्ट एन्ड। त्यो यातायात जानकारी हो र अरू केहि छैन। पहिचान IKEv2 आईडी पेलोडमा हुन्छ र त्यसपछि साथीको प्रमाणपत्रसँग मेल खान्छ। ठेगाना बाकसमा एउटा DNS नाम अपेक्षित पहिचान बन्दैन, र कच्चा आईपी पहिचान बन्दैन किनभने सकेट यसमा जडान हुन्छ।

strongSwan सर्तहरूमा, ठेगाना right वा left हो, र अपेक्षित पहिचान rightid वा leftid हो, र त्यो IKEv2 कन्फिगरेसन कागजात ले वर्णन गर्दछ। यदि तपाईंले कहिल्यै ठेगाना सम्पादन गर्नुभएको छ भने, तपाईंले जोडीको आधा कन्फिगर गर्नुभएको छ।

दोस्रो, प्रमाणपत्रले के प्रमाणित गर्न सक्छ

पहिचानको एक प्रकार छ, र प्रमाणपत्रमा मिल्दो नाम बोक्नुपर्छ। एक DNS पहिचान विषय वैकल्पिक नाम विस्तार मा dNSName प्रविष्टि द्वारा सन्तुष्ट छ; आईपी पहिचानलाई iPAddress प्रविष्टि चाहिन्छ। vpn.example.com को लागि जारी गरिएको प्रमाणपत्रले शाब्दिक ठेगाना 203.0.113.10 को बारे मा केहि प्रमाणित गर्दैन, र त्यो ठेगाना को लागी जारी गरिएको एक नाम को बारे मा केहि प्रमाणित गर्दैन। एउटै कुञ्जी र CA पुन: प्रयोग गर्दा पनि फरक नामको लागि पुन: जारी गर्नु ड्रप-इन प्रतिस्थापन होइन।

आधुनिक ग्राहकहरूले विषयको वैकल्पिक नाम अवस्थित हुँदा सामान्य नामलाई बेवास्ता गर्छन्, र धेरैले यसलाई पूर्ण रूपमा बेवास्ता गर्छन्। यदि SAN सूचीमा क्लाइन्टले जाँच गरेको मान समावेश गर्दैन, प्रमाणपत्र पहिले नै विश्वसनीय रूपमा स्वीकार गरिसकेपछि ह्यान्डशेक असफल हुन्छ, त्यसैले लगले विश्वास त्रुटिको सट्टा पहिचान त्रुटि जस्तै पढ्छ।

तेस्रो, कसरी प्रत्येक ग्राहकले अपेक्षा बताउँछ

Windows ले तपाईंले टाइप गर्नुभएको सर्भरको नाम वा ठेगाना लिन्छ र यसलाई मिलाउन प्रमाणपत्र चाहिन्छ, त्यसैले IP टाइप गर्दा IP अपेक्षा सिर्जना हुन्छ। Android को IKEv2 क्लाइन्टले उस्तै व्यवहार गर्छ, र दुबैले एक मान्य, सार्वजनिक रूपमा विश्वसनीय प्रमाणपत्र अस्वीकार गर्दछ जसले फरक होस्टको नाम दिन्छ। माइग्रेसनको क्रममा कसैले होस्टनामलाई यसको ठेगानासँग प्रतिस्थापन गरेकोले प्रोफाइल असफल हुन थाल्छ। प्रमाणपत्रमा के समावेश छ भनेर हेर्नु अघि ग्राहकले के मागेको हेर्नुहोस्।

strongSwan मा अपेक्षा स्पष्ट छ: सर्भरले वास्तवमा प्रस्तुत गरेको पहिचानमा rightid सेट गर्नुहोस्, जुन दायाँबाट फरक हुन सक्छ। यसलाई %any मा सेट गर्नाले पियरले जे पनि प्रस्ताव गर्छ स्वीकार गर्छ र तपाईले राख्न खोजेको चेकलाई हटाउँछ।

चौथो, सहकर्मी पहिचानबाट अलग प्रयोगकर्ता लगइन

EAP प्रमाणीकरण र सर्भर पहिचानले विभिन्न प्रश्नहरूको जवाफ दिन्छ। एक EAP पहिचान जस्तै [email protected] ले प्रयोगकर्ता को हो भनेर बताउँछ, ग्राहकले सर्भर सही हो भनेर निर्णय गरेपछि। त्यो पासवर्ड घुमाउँदा सहकर्मी पहिचान बेमेल मिलाउन सक्दैन, किनभने जडान कहिल्यै प्रयोगकर्ता-लगइन चरणमा पुग्दैन।

सेनिटाइज गरिएको रिपोर्टमा दुवैको नाम हुनुपर्छ: ग्राहकले अपेक्षा गरेको पहिचान, सर्भरले प्रस्तुत गरेको पहिचान, र प्रमाणपत्रको SAN प्रविष्टिहरू।

पाँचौं, प्रमाणित च्यानल मार्फत परिवर्तन गर्नुहोस्

जब गेटवे वैध रूपमा सर्छ, पहिले ठेगाना अपडेट गर्नुहोस् र पहिचान एक्लै छोड्नुहोस्, किनभने यो मामला IKEv2 ले राम्रोसँग ह्यान्डल गर्छ। जब पहिचान आफै परिवर्तन हुन्छ, यसलाई विश्वास घटनाको रूपमा व्यवहार गर्नुहोस् र तपाईंले पहिले नै विश्वास गर्नुभएको स्रोतबाट नयाँ मान प्राप्त गर्नुहोस्, हाल असफल भइरहेको अन्तिम बिन्दुबाट होइन। तपाईंले प्रमाणित गर्न खोज्नु भएको जडानमा पठाइएको सन्देश त्यो जडानको प्रमाण होइन।

प्रोफाइल नोटहरूमा अन्तिम ठेगाना, पहिचान र SAN सूची सँगै रेकर्ड गर्नुहोस्। प्रमाणपत्र छुने अर्को व्यक्तिले त्यसपछि तीन मध्ये कुनलाई सार्न अनुमति दिइएको छ भनेर देख्नेछ।