IKEv2 एक्सचेंज काम करता है, फिर प्रमाणीकरण विफल होता है: कहाँ देखें

IKEv2 प्रतिक्रिया पाने वाला क्लाइंट सिद्ध कर चुका है कि गेटवे पहुँच योग्य है, दोनों पक्ष किसी प्रस्ताव पर बातचीत कर सकते हैं और प्रारंभिक कुंजी एक्सचेंज पूरा हुआ। उसने यह सिद्ध नहीं किया कि किसी का प्रमाणीकरण हुआ है। अगला एक्सचेंज पहचान, प्रमाणपत्र या EAP ले जाता है, और वहीं कनेक्शन आमतौर पर रुक जाता है। इनमें से कौन-सी जाँच विफल हुई, यह पढ़ना ही पूरा निदान है, और केवल त्रुटि संदेश यह शायद ही बताता है।

जाँच 1: चरण पढ़ें, संदेश नहीं

अस्वीकृति तीन जगहों से आ सकती है: क्लाइंट सर्वर की पहचान अस्वीकार करता है, गेटवे क्लाइंट का प्रमाण अस्वीकार करता है, और कोई बाहरी प्रमाणीकरण सेवा खाता अस्वीकार करती है।

हर एक अलग मशीन पर अलग लॉग पंक्ति बनाता है, और हर एक का अलग उपाय है। क्लाइंट की ओर से सर्वर प्रमाणपत्र की अस्वीकृति क्लाइंट पर भरोसा या नामकरण की समस्या है; गेटवे की ओर से क्लाइंट प्रमाणपत्र की अस्वीकृति गेटवे पर भरोसे की समस्या है; EAP विफलता खाते या बैकएंड की समस्या है। आप जो संदेश देखते हैं वह आमतौर पर इनमें से किसी एक का क्लाइंट द्वारा किया गया सारांश है, इसलिए गेटवे का लॉग क्लाइंट के लॉग जितना ही महत्वपूर्ण है।

जाँच 2: कौन-सी पहचान जाँची गई

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

strongSwan की शब्दावली में यह क्लाइंट पर rightid है और दूसरी ओर गेटवे की अपनी पहचान, और EAP पर चर्चा होने से पहले ही बेमेल विफल हो जाता है।

गेटवे अलग से क्लाइंट का प्रमाणपत्र, उसका कुंजी प्रमाण या उसके खाते का प्रमाणीकरण अस्वीकार कर सकता है, और ये तीन विनिमेय नहीं हैं। उपयोगकर्ता का पासवर्ड रीसेट करने से डिवाइस प्रमाणपत्र नवीनीकृत नहीं होता, और डिवाइस प्रमाणपत्र फिर से स्थापित करने से गलत सर्वर पहचान ठीक नहीं होती। प्रमाणपत्र विफलताओं के लिए पहले घड़ी देखें, फिर भरोसा श्रृंखला, फिर अपेक्षित पहचानकर्ता; जिसकी घड़ी कुछ मिनट आगे-पीछे है वह वैधता जाँच में विफल होता है जो भरोसा विफलता जैसी दिखती है। swanctl --list-certs दोनों सिरों पर दिखाता है कि हर पक्ष वास्तव में क्या रखता है।

जाँच 3: अगर EAP शामिल है

क्लाइंट और सर्वर को समर्थित विधि पर सहमत होना होगा, और बैकएंड को दी गई पहचान स्वीकार करनी होगी।

उपयोगकर्ता नाम को डोमेन प्रत्यय या तैनाती द्वारा मांगा गया विशिष्ट खाता प्रारूप चाहिए हो सकता है, और प्रारूप अनुमान लगाने योग्य नहीं बल्कि प्रलेखित है। ऑपरेटर के प्रलेखित फ़ील्ड देना विविधताएँ आज़माने से तेज़ है, और यह दूसरी समस्या टालता है: बार-बार प्रयास खाता लॉकआउट कर सकते हैं, जो फिर मूल चरण को नई विफलता के पीछे छिपा देता है। अगर विधि किसी निर्देशिका के विरुद्ध EAP-MSCHAPv2 है, तो विफलता VPN की नहीं बल्कि निर्देशिका की हो सकती है।

पहचान जाँच बंद करके पहचान की समस्याओं का परीक्षण न करें। यह निदान योग्य विफलता को अनिदान योग्य बना देता है और कनेक्शन को पहले से कमजोर छोड़ देता है।

जाँच 4: सफल लॉगिन के बाद क्या होता है

IKE_AUTH पूरा होने के बाद, CHILD_SA बातचीत तय करती है कि कौन-से ट्रैफ़िक चयनकर्ता स्थापित होंगे, और वहीं कनेक्शन सफल होकर भी कुछ नहीं भेज सकता।

नया काम करने लगा लॉगिन अक्सर ऐसी चयनकर्ता या मार्ग समस्या उजागर करता है जो पहले प्रमाणीकरण विफलता के पीछे छिपी थी। अगर टनल ऊपर आ जाती है और कोई एप्लिकेशन फिर भी अपने गंतव्य तक नहीं पहुँचता, तो फिर से पहचान के बजाय सहमत चयनकर्ताओं और मार्गों को देखें। उस समय पहचान सेटिंग्स बदलना गलत चरण को लक्षित करता है और आमतौर पर काम कर रहा लॉगिन तोड़ देता है। swanctl --list-sas से पुष्टि करें, जो IKE SA से अलग चिल्ड्रन और उनके चयनकर्ता दिखाता है।

जाँच 5: सहायता को क्या दें

साफ़ किया गया समयरेखा और सटीक अस्वीकृति पूर्ण निदान निर्यात से अधिक मूल्यवान हैं, और निर्यात में निजी कुंजियाँ या क्रेडेंशियल हो सकते हैं जिन्हें आपको साझा नहीं करना चाहिए।

समय क्षेत्र के साथ समय, क्लाइंट और गेटवे के संस्करण, विधि, पासवर्ड के बजाय दी गई पहचान स्ट्रिंग, और वह सटीक चरण जिसने इसे अस्वीकार किया, दर्ज करें। strongSwan IKEv2 कॉन्फ़िगरेशन दस्तावेज़ उन पहचान और EAP सेटिंग्स का वर्णन करता है जो इन परिणामों को तय करती हैं, और किसी फ़ील्ड को बदलने से पहले पढ़ने के लिए यही संदर्भ है। फिर एक चीज़ बदलें और नया कनेक्शन फिर से जाँचें, क्योंकि कैश सत्र आपको पुराने कॉन्फ़िगरेशन के बारे में बताएगा।