IKEv1, XAuth और OTP के साथ: हर प्रॉम्प्ट क्या मांगता है

IKEv1 PSK, XAuth और OTP के साथ एक जटिल पासवर्ड नहीं मांगता। यह सहकर्मियों के बीच एक साझा कुंजी, एक उपयोगकर्ता विनिमय और एक दूसरा कारक परत-दर-परत रखता है, जिसे कैसे मांगना है यह बैकएंड तय करता है। हर परत का अपना मालिक और अपना विफलता संदेश है। इन्हें मिला देने से लोग समूह रहस्य रखने वाले फ़ील्ड में एक-बार का कोड फिर लिखने लगते हैं।

दूसरा क्लाइंट स्थापित करने या क्रेडेंशियल रीसेट करने से पहले हर प्रॉम्प्ट को उस परत से मिलाएँ जो उसे मांगती है।

तीन रहस्य, तीन मालिक

पूर्व-साझा कुंजी सहकर्मी संबंध की है और जो दोनों सिरों का मालिक है वह इसे एक बार कॉन्फ़िगर करता है। उपयोगकर्ता क्रेडेंशियल प्रमाणीकरण बैकएंड का है और हर लॉगिन पर सत्यापित होता है। दूसरा कारक टोकन प्रणाली का है जिसका उत्तर हर प्रयास में बदलता है। कोई किसी का विकल्प नहीं है, और जो परिनियोजन इन्हें एक पासवर्ड मानता है वह उस परत पर विफल होता है जिसे किसी ने प्रलेखित नहीं किया।

तीन कॉलम लिखें: मालिक, आयु और हर एक से निकलने वाला विफलता संदेश। वही तालिका निदान का साधन है, क्लाइंट के फ़ील्ड नाम नहीं।

PSK: सहकर्मी, व्यक्ति नहीं

पूर्व-साझा कुंजी इस पुरानी व्यवस्था में गेटवे जोड़ी को प्रमाणित करती है, इसलिए उपयोगकर्ता का लॉगिन इसे कभी नहीं बदलता। यह वह मान भी है जो सबसे अधिक गलत होने की संभावना रखता है, ऐसे कि प्रॉम्प्ट की जगह एक सामान्य वार्ता त्रुटि आती है। जब कोई उपयोगकर्ता प्रॉम्प्ट दिखने से पहले ही टनल विफल हो, तो संदिग्ध कुंजी या प्रस्ताव होते हैं।

उपयोगकर्ता क्रेडेंशियल पहले चरण की विफलता ठीक नहीं कर सकता। इसे घुमाने से वही एकमात्र क्रेडेंशियल बर्बाद होता है जिसे आप सुरक्षित रूप से घुमा सकते हैं, और गलत सिद्धांत मजबूत होता है।

XAuth: पुराना उपयोगकर्ता विनिमय

XAuth IKEv1 के सहकर्मी प्रमाणीकरण के ऊपर उपयोगकर्ता प्रमाणीकरण विनिमय जोड़ता है, और कौन सा बैकएंड इसे सत्यापित करेगा यह गेटवे तय करता है। उस बैकएंड के अनुसार विनिमय डायरेक्टरी पासवर्ड, RADIUS क्रेडेंशियल या टोकन उत्तर स्वीकार कर सकता है। XAuth शब्द क्रेडेंशियल का प्रकार नहीं, विनिमय का परिवहन बताता है।

देखें कि गेटवे प्रोफ़ाइल किस बैकएंड की ओर इशारा करता है। यह बताता है कि उपयोगकर्ता से क्या मांगा जाएगा और पासवर्ड रीसेट वास्तव में क्या बदलता है, और इनमें से कोई भी क्लाइंट प्रोफ़ाइल में दिखाई नहीं देता।

OTP: जो बैकएंड मांगे

कुछ परिनियोजन पासवर्ड के बाद अलग एक-बार का कोड मांगते हैं, और अन्य प्रलेखित विभाजक के साथ संयुक्त इनपुट प्रारूप परिभाषित करते हैं। दोनों मौजूद हैं, और आपके सामने का प्रोफ़ाइल तय करता है कौन सा। दूसरी जगह काम करने के कारण जोड़ बनाना पंजीकरण टोकन जलाने का सबसे आम तरीका है। गेटवे का अपना प्रलेखन ही एकमात्र स्रोत है जो इसे तय करता है।

प्रलेखित प्रारूप का उपयोग ऐसे क्लाइंट के साथ करें जो गेटवे द्वारा दिए गए विनिमय को पूरा कर सके।

क्लाइंट की सीमा कहाँ काटती है

Fortinet प्रलेखित करता है कि FortiClient 7.4.4 और बाद के संस्करण IPsec VPN के लिए IKEv1 का समर्थन नहीं करते, जो सार्वभौमिक हटाव नहीं बल्कि उत्पाद और संस्करण की सीमा है, जैसा FortiClient संगतता नोट दर्ज करता है। अन्य क्लाइंट भी विनिमेय नहीं हैं: OpenConnect और openfortivpn विशिष्ट गेटवे प्रोटोकॉल बोलते हैं, मनमानी IKEv1 प्रोफ़ाइल नहीं। स्थापित क्लाइंट का IKE संस्करण, PSK मोड, XAuth समर्थन और अंतःक्रिया मॉडल अलग-अलग जाँचें। जो क्लाइंट किसी दूसरी विधि से जुड़ता है उसने मूल आवश्यकता सिद्ध नहीं की।

IKEv1 अप्रचलित है, इसलिए असमर्थित पुराने क्लाइंट पर नया रोलआउट अल्पकालिक समाधान है। गेटवे मालिक से समर्थित माइग्रेशन मार्ग मांगें, जिसमें यह भी शामिल हो कि वहाँ दूसरा कारक कैसे संभाला जाएगा।

कारक को बंद किए बिना निदान

लॉग में चरण अलग करें: सहकर्मी वार्ता, उपयोगकर्ता विनिमय, दूसरे कारक का परिणाम, फिर पता और मार्ग आवंटन। हर फ़ील्ड में कोड आज़माने के बजाय घटक और चरण दर्ज करें। परीक्षण पास कराने के लिए कारक बंद करने से ऐसी टनल बनती है जो परिनियोजन के बारे में कुछ सिद्ध नहीं करती।

पंजीकरण रहस्य और साझा कुंजी संगठन की प्रक्रिया के अनुसार संरक्षित भंडारण में रखें। स्थायी फ़ाइल में रखा एक-बार का कोड ऐसा कारक है जो कारक रहना बंद हो चुका है।