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 विधि, पहिचान स्ट्रिङ, प्राधिकरण स्रोत र समर्थन सकिने मिति।