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 पद्धत, ओळख स्ट्रिंग, प्राधिकरण स्रोत आणि समर्थन संपणारी तारीख।