गेटवे प्रमाणपत्र ठीक है: IKEv2 PEAP लॉगिन फिर भी क्यों विफल होता है

आपके VPN गेटवे का प्रमाणपत्र मान्य है, श्रृंखला सत्यापित होती है, और IKEv2 क्लाइंट प्रमाणपत्र की वैधता अवधि के बारे में संदेश के साथ लॉगिन फिर भी अस्वीकार कर देता है। पहली प्रवृत्ति गेटवे प्रमाणपत्र फिर से जारी करने या EAP विधि बदलने की होती है, और दोनों आम तौर पर गलत हैं। लॉगिन का प्रयास दो अलग सर्वर पहचानें लेकर चलता है: IKE द्वारा उपयोग किया जाने वाला गेटवे प्रमाणपत्र, और वह प्रमाणपत्र जो PEAP को समाप्त करने वाला प्रस्तुत करता है। इनमें से एक ठीक है, और दूसरी ही वह कारण है जिससे क्लाइंट रुका।

दो पहचानें, एक लॉगिन प्रयास

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

यह स्तर-व्यवस्था बताती है कि प्रमाणपत्र त्रुटि ऐसी जगह क्यों दिखती है जहाँ किसी ने केवल गेटवे का प्रमाणपत्र ही कॉन्फ़िगर किया था। यह भी बताती है कि उस प्रमाणपत्र को फिर से जारी करने से कुछ क्यों नहीं बदलता।

लॉग पंक्ति को चरण के सामने पढ़ें

वह संदेश खोजें जिसमें कारण और तारीखें दी गई हों। विषय त्रुटि के बगल में वैधता अवधि की शिकायत का अर्थ है कि सर्वर ने उसे दिया गया प्रमाणपत्र अस्वीकार किया, यह नहीं कि उपयोगकर्ता ने लॉगिन अस्वीकार किया। फिर चरण खोजें: strongSwan का charon लॉग EAP विनिमय शुरू होने से पहले IKE_SA .* established दिखाता है, इसलिए उस पंक्ति के बाद की प्रमाणपत्र त्रुटि EAP पहचान की है, जबकि उससे पहले की त्रुटि गेटवे की ओर संकेत करती है। Windows क्लाइंट के कनेक्शन पैनल में चरण का पाठ भी यही कहता है।

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

पता लगाएँ कि PEAP कौन-सा अंतिम बिंदु समाप्त करता है

गेटवे-प्लस-RADIUS डिज़ाइन में गेटवे EAP आगे भेजता है और उसे समाप्त नहीं करता। strongSwan का eap-radius प्लगइन विनिमय RADIUS सर्वर को सौंप देता है, जिसके पास PEAP TLS सत्र और उसका प्रमाणपत्र होता है। दोनों लॉग में एक विफल प्रयास का सहसंबंध बनाएँ और पुष्टि करें कि किस प्रक्रिया ने वास्तव में उस सत्र के लिए प्रमाणपत्र चुना।

NPS के लिए प्रमाणपत्र स्थानीय कंप्यूटर स्टोर में होना चाहिए, सर्वर प्रमाणीकरण का उद्देश्य रखना चाहिए, क्लाइंट जिस नाम की अपेक्षा करते हैं उससे मेल खाना चाहिए, और सेवा खाते के लिए पठनीय होना चाहिए। NPS के लिए Microsoft की प्रमाणपत्र आवश्यकताएँ इन शर्तों को सूचीबद्ध करती हैं। अन्य EAP सर्वरों के अपने चयन नियम हैं, इसलिए NPS की बारीकियाँ FreeRADIUS परिनियोजन में या इसके विपरीत न कॉपी करें। जो नियम दोनों स्थितियों में टिकता है वह यह है कि PEAP को समाप्त करने वाला अंतिम बिंदु उस प्रमाणपत्र का स्वामी है जिसे आप बदलने वाले हैं।

प्रमाणपत्र वहीं बदलें जहाँ EAP समाप्त होता है

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

अगले प्रयास को सेवा के अपने लॉग से सहसंबंधित करके, या सत्र द्वारा प्रस्तुत प्रमाणपत्र का निरीक्षण करके परिवर्तन की पुष्टि करें। यदि वह लॉग अब भी पुराना थंबप्रिंट दिखाता है, तो पुनः आरंभ काम नहीं आया।

यह न मानें कि किसी निर्देशिका की सबसे नई फ़ाइल ही उपयोग में है। सही नाम और गलत अनुमतियों वाली प्रति कुछ नहीं बदलती। परिवर्तन को प्रस्तुत पहचान से आँकें, फ़ाइल के टाइमस्टैम्प से नहीं।

क्या न करें

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

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