गेटवे प्रमाणपत्र ठीक आहे: 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 पद्धत, वेगळा ट्रस्ट स्टोअर किंवा अजिबात सर्व्हर सत्यापन न वापरू शकतो, त्यामुळे त्याचे यश येथे अयशस्वी झालेल्या तपासणीबद्दल काहीच सांगत नाही। एक जाणीवपूर्वक नकारात्मक चाचणी ठेवा, उदाहरणार्थ चुकीच्या नावाचे प्रमाणपत्र किंवा अविश्वासार्ह साखळी, जी अपेक्षेप्रमाणे अयशस्वी होते। ती चाचणी आता उत्तीर्ण झाली, तर तुम्ही प्रमाणपत्र दुरुस्त करण्याऐवजी तपासणी काढून टाकली आहे। कोणती ओळख अयशस्वी झाली ते लिहून ठेवा, जेणेकरून पुढच्या व्यक्तीने पुन्हा गेटवे प्रमाणपत्रापासून सुरुवात करू नये।