IKEv1 का हाइब्रिड प्रमाणीकरण IKEv2 के उपयोगकर्ता प्रमाणीकरण में कैसे बदलता है
हाइब्रिड मोड गेटवे के प्रमाण को उपयोगकर्ता के प्रमाण से अलग रखता था। IKEv2 पर जाने से यह अलगाव बना रहता है, पर आदान-प्रदान, EAP विधि और प्रमाणपत्र की जाँच बदल जाती है।
हर पुराना VPN प्रोफ़ाइल जो पहले सर्वर प्रमाणपत्र और फिर उपयोगकर्ता नाम माँगता है, एक ही आदान-प्रदान में प्रमाणीकरण की दो घटनाएँ लिए चलता है, और यह आकार उस प्रोटोकॉल से अधिक जीता है जिसने इसे लाया। IKEv1 का हाइब्रिड मोड ठीक इसी के लिए बना था: गेटवे खुद को सार्वजनिक कुंजी से सिद्ध करता है और उपयोगकर्ता बाद में XAuth के जरिए खुद को सिद्ध करता है। IKEv2 वही दो-चरणीय विचार दूसरी मशीनरी से व्यक्त करता है, और इन्हीं अंतरों में माइग्रेशन विफल होते हैं। कोई संस्करण संख्या एक को दूसरे में नहीं बदलती, और पुराने विकल्पों के नाम नई प्रोफ़ाइल में नकल करने से ऐसा क्लाइंट मिलता है जो बातचीत करता है और फिर कुछ भी प्रमाणित नहीं करता।
हाइब्रिड मोड ने IKEv1 के भीतर क्या किया
हाइब्रिड प्रोफ़ाइल में उत्तरदाता पक्ष पहले चरण के आदान-प्रदान पर अपने प्रमाणपत्र से हस्ताक्षर करता है जबकि आरंभकर्ता जानबूझकर कोई प्रमाणपत्र नहीं दिखाता। इसलिए पहचान का प्रमाण असममित है, और इसी ने गेटवे को अपना मौजूदा PKI रखने और उपयोगकर्ताओं को अपने डायरेक्टरी पासवर्ड रखने दिए। पहला चरण पूरा होने पर XAuth अनुरोध और उत्तर के रूप में चलता है जो अब एन्क्रिप्टेड ISAKMP चैनल के भीतर उपयोगकर्ता नाम और पासवर्ड के गुण ले जाता है।
ध्यान दें कि भरोसा कहाँ पहुँचता है। प्रमाणपत्र बताता है कि क्लाइंट किस गेटवे तक पहुँचा; XAuth बताता है कि कौन उपयोगकर्ता पहुँच चाहता है। कोई किसी की जगह नहीं लेता, और किसी भी सर्वर प्रमाणपत्र को स्वीकार करने पर सेट क्लाइंट चुपचाप पहला उत्तर फेंक चुका है। हाइब्रिड का लेबल पहले से साझा कुंजी और XAuth वाले आक्रामक मोड के लिए भी प्रयोग होता है, जो उसी उपयोगकर्ता अनुभव वाली अलग व्यवस्था है, इसलिए नाम नहीं, प्रोफ़ाइल पढ़ें। दोनों रूप ऐसे मसौदों से आते हैं जो कभी मानक नहीं बने, और इसीलिए दो निर्माता हाइब्रिड मोड लागू कर सकते हैं और किसी के साथ अंतर-संचालन नहीं कर सकते।
IKEv2 उन्हीं दो प्रमाणों तक कैसे पहुँचता है
IKEv2 काम को IKE_SA_INIT और IKE_AUTH में बाँटता है। पहला आदान-प्रदान बिना किसी पहचान के प्रस्तावों और कुंजियों पर सहमत होता है; दूसरा IDi, IDr और AUTH पेलोड ले जाता है। EAP के अंतर्गत आरंभकर्ता का पहला AUTH पेलोड खाली जाता है, उत्तरदाता पहले अपने प्रमाणपत्र और हस्ताक्षर से प्रमाणित होता है, और फिर EAP बातचीत IKE_AUTH संदेशों के भीतर चलती है।
इसे सुरक्षित बनाने वाली मशीनरी कुंजी सामग्री है। सफल EAP विधि एक सत्र कुंजी निर्यात करती है, और आरंभकर्ता का अंतिम AUTH पेलोड उससे परिकलित होता है, इसलिए उपयोगकर्ता का प्रमाण और सुरंग की कुंजियाँ आपस में बँधी रहती हैं। XAuth का ऐसा कोई समतुल्य नहीं: उसके गुण पहले चरण के बाद आते हैं और कुंजियों में कुछ नहीं जोड़ते। यही अंतराल IKEv2 ढाँचे को भरने के लिए बनाया गया था, और इसीलिए काम करता IKEv2 लॉगिन कुछ भी माँगने से पहले सर्वर प्रमाणपत्र की पुष्टि करता है।
यह क्रम एक उपयोगी निदान भी है। जब क्लाइंट आपको प्रमाणपत्र दिखाने से पहले ही क्रेडेंशियल की शिकायत करता है, तो वह IKEv2 EAP आदान-प्रदान बिल्कुल नहीं कर रहा।
तीन पहचानें अलग रखें
माइग्रेशन तब बिगड़ता है जब तीन पहचानें एक ही फ़ील्ड में समा जाती हैं। गेटवे की पहचान है जिसे क्लाइंट सत्यापित करता है, आमतौर पर प्रमाणपत्र के subject या SAN में DNS नाम। EAP में प्रस्तुत उपयोगकर्ता की पहचान है, हो सकता है डोमेन लॉगिन, पता या स्पष्ट EAP पहचान स्ट्रिंग। और वह प्राधिकरण स्रोत है जो उस उपयोगकर्ता को नेटवर्क और मार्गों पर प्रतिचित्रित करता है।
strongSwan का swanctl सिंटैक्स अलगाव को दिखाता है: कनेक्शन गेटवे के लिए remote { auth = pubkey } और उपयोगकर्ता के लिए local { auth = eap-mschapv2 } सेट करता है, और EAP पहचान अलग ढोई जाती है।
जब नई प्रोफ़ाइल में उपयोगकर्ता की पहचान पुराने XAuth गुणों से भिन्न हो, जैसे छोटे नाम की जगह UPN, प्रमाणीकरण सर्वर अज्ञात उपयोगकर्ता देखता है और विफलता गलत पासवर्ड जैसी लगती है। क्रेडेंशियल जाँचने से पहले पहचान स्ट्रिंग जाँचें।
विकल्पों का मानचित्र बनाएँ और फिर जाल की अपेक्षा करें
मानचित्रण छोटा है और हर पंक्ति में एक जाल है जो केवल प्रमाणीकरण के समय दिखता है।
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
उन पंक्तियों में से कोई भी केवल नाम बदलना नहीं है। कॉन्फ़िगरेशन पेलोड पते और रिज़ॉल्वर टाइप किए गए गुण सूची से पहुँचाता है, जबकि XAuth का गुण क्षेत्र उसका अपना आविष्कार था; उन्हें विनिमेय मानना वही रास्ता है जिससे प्रोफ़ाइल ऐसी सेटिंग माँगने लगती है जो गेटवे कभी नहीं भेजेगा।
ट्रैफ़िक चयनकर्ता अपनी अलग चेतावनी के हकदार हैं। IKEv1 रोचक ट्रैफ़िक को quick mode आदान-प्रदान से बँधे प्रॉक्सी आईडी से व्यक्त करता था, जबकि IKEv2 चयनकर्ताओं पर IKE_AUTH के दौरान बातचीत करता है और उत्तरदाता उन्हें संकरा कर सकता है। बेमेल होने पर child SA के बिना स्थापित IKE SA बनता है, जिसे कुछ क्लाइंट खुशी से जुड़ा दिखाते हैं।
पुराने कनेक्शन को सीमा मानें
RFC 9395 IKEv1 को अप्रचलित घोषित करता है, इसलिए पुराना हाइब्रिड कनेक्शन तिथि वाली अनुकूलता की सीमा है, नींव नहीं। बदलाव के दौरान दोनों प्रोफ़ाइल साथ-साथ चलाएँ, क्योंकि महत्वपूर्ण परीक्षण यह नहीं कि नई प्रोफ़ाइल उठती है या नहीं, बल्कि यह कि वही उपयोगकर्ता उसी डिवाइस पर उन्हीं संसाधनों तक पहुँचता है।
प्रमाणपत्र सत्यापन को शुरू से अंत तक कड़ा रखें। जैसे ही क्लाइंट अपना प्रमाणपत्र दिखाना बंद करता है, ललच होता है कि सर्वर जाँच ढीली कर दी जाए जब तक हैंडशेक पूरा हो, और यह बचा हुआ एकमात्र प्रमाण हरे आइकन से बदल देता है।
पुरानी प्रोफ़ाइल हटाने से पहले चार बातें लिखें: EAP विधि, पहचान स्ट्रिंग, प्राधिकरण स्रोत और वह तिथि जब समर्थन समाप्त होता है।