गेटवे प्रमाणपत्र ठीक छ: IKEv2 PEAP लगइन किन अझै असफल हुन्छ

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

दुई पहिचान, एक लगइन प्रयास

VPN प्रोफाइलमा भएको प्रमाणपत्र IKE आदानप्रदानको हो: कन्फिगर गरिएको IKE नीतिअनुसार गेटवे प्रोफाइलले नाम दिएको पक्ष हो भनी यसले प्रमाणित गर्छ। यहाँ असफल हुने प्रमाणपत्र अर्कै कुराकानीको हो, अर्थात् PEAP ले प्रयोगकर्तालाई प्रमाणित गर्नेसँग खोल्ने TLS सत्र, जुन प्रायः गेटवे आफैं नभई 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 विधि, फरक ट्रस्ट स्टोर वा सर्भर प्रमाणीकरण नै नभएको अवस्था प्रयोग गर्न सक्छ, त्यसैले त्यसको सफलताले यहाँ असफल भएको जाँचबारे केही भन्दैन। एउटा जानाजान गरिएको नकारात्मक परीक्षण राख्नुहोस्, जस्तै गलत नामको प्रमाणपत्र वा अविश्वसनीय श्रृंखला, जो अपेक्षाअनुसार असफल हुन्छ। यदि त्यो परीक्षण अहिले उत्तीर्ण हुन्छ भने तपाईंले प्रमाणपत्र सुधार्नुको सट्टा जाँच हटाउनुभएको छ। कुन पहिचान असफल भयो लेख्नुहोस्, ताकि अर्को व्यक्तिले फेरि गेटवे प्रमाणपत्रबाट सुरु नगरोस्।