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 सूची को एक साथ रिकॉर्ड करें। प्रमाणपत्र को छूने वाला अगला व्यक्ति देखेगा कि तीनों में से किसे स्थानांतरित करने की अनुमति है।