सही VPN पासवर्डले हराएको प्रमाणपत्रको सट्टा लिन सक्दैन

प्रमाणहरू सही छन्, प्रोफाइल सफा रूपमा आयात हुन्छ, र प्रमाणीकरण पूरा हुनुअघि नै जडान असफल हुन्छ। Windows मा सन्देश EAP विधिका लागि नभेटिएको प्रमाणपत्रको बारेमा त्रुटि 798 हुन सक्छ। OpenVPN मा ग्राहक लगले सर्भरलाई कहिल्यै सन्तुष्ट नगर्ने TLS ह्यान्डसेक देखाउँछ। दुवैले एउटै हराएको वस्तुको वर्णन गर्छन्: ग्राहकले प्रस्तुत गर्नुपर्ने ग्राहक प्रमाणपत्र।

पासवर्डले रहस्यको ज्ञान प्रमाणित गर्छ; प्रमाणपत्रले कुञ्जीको स्वामित्व प्रमाणित गर्छ, र एउटाले अर्कोलाई प्रतिस्थापन गर्दैन।

पासवर्ड कहिल्यै समस्या थिएन

त्रुटि 798 प्रमाणपत्र खोजीको असफलता हो। ग्राहकलाई कन्फिगर गरिएको प्रमाणीकरण विधिसँग मिल्ने प्रमाणपत्र मागियो, उसले आफ्नो भण्डार खोज्यो र प्रयोगयोग्य केही भेटेन। यसको अर्थ प्रमाणपत्र छैन, निजी कुञ्जी बिना छ, म्याद सकिएको छ, वा खोजी नपुग्ने ठाउँमा भण्डारण गरिएको छ भन्ने हुन सक्छ। पासवर्ड फेरि प्रयास गर्दा यीमध्ये कुनै पनि अवस्था बदलिँदैन, त्यसैले सही प्रमाणहरूसँग पनि त्रुटि फर्किन्छ।

कार्य गर्नुअघि सन्देश पढ्नुहोस्। प्रमाण अस्वीकृति, प्रमाणपत्र खोजीको असफलता र TLS ह्यान्डसेकको असफलता तीन फरक निष्कर्ष हुन्, र तीमध्ये एउटाले मात्र पासवर्डसँग सम्बन्ध राख्छ।

ग्राहक भण्डारमा के हुनुपर्छ

दुई वस्तु संलग्न छन्। ग्राहक प्रमाणपत्र VPN ग्राहक चलाउने प्रयोगकर्ताका लागि उसको निजी कुञ्जीसहित स्थापना गरिनुपर्छ, र जारी गर्ने मूल विश्वसनीय हुनुपर्छ। .cer फाइलमा सार्वजनिक प्रमाणपत्र मात्र हुन्छ, त्यसैले यसले एक्लै केही पनि प्रमाणित गर्न सक्दैन। Windows प्रमाणपत्र प्रबन्धकमा, ग्राहक पहिचान हालको प्रयोगकर्ताको व्यक्तिगत भण्डारमा हुन्छ, र मूल विश्वसनीय मूल भण्डारमा हुन्छ।

पहिचानलाई मेसिन भण्डारमा, वा मात्र मूल भण्डारमा स्थापना गर्दा प्रयोगकर्ताको व्यक्तिगत भण्डारमा लक्षित खोजी पूरा हुँदैन। भण्डार, निजी-कुञ्जी झन्डा र वैधता मितिहरू सँगै जाँच्नुहोस्, त्यसपछि भण्डार फेरि पढ्न ग्राहक पुनः सुरु गर्नुहोस्।

दुई उत्पादन, एउटै हराएको प्रमाण

OpenVPN सर्भरहरूले पूर्वनिर्धारित रूपमा ग्राहक प्रमाणपत्र माग्छन्। ग्राहकमा auth-user-pass थप्दा प्रयोगकर्ता नाम र पासवर्ड पठाइन्छ, र TLS ह्यान्डसेकले अझै प्रमाणपत्र माग्छ, त्यसैले मात्र पासवर्डले verify-client-cert require अन्तर्गत जडान पूरा गर्न सक्दैन। सर्भरलाई केही नमाग्ने गरी सेट गर्न सकिन्छ, जसले पासवर्डलाई ग्राहकको एकमात्र प्रमाण बनाउँछ र यो शक्तिमा वास्तविक कमी हो। auth-user-pass-verify पछाडिको shell स्क्रिप्टले प्रमाणहरू प्रमाणित गर्न सक्छ, र यसका लागि स्क्रिप्ट कार्यान्वयन सक्षम हुनुपर्छ, जसले यसलाई उपयुक्त प्रमाणीकरण ब्याकएन्डभन्दा जोखिमपूर्ण डिजाइन बनाउँछ।

मात्र पासवर्डमा आधारित प्रोफाइल पनि धकेलिएका विकल्पहरूमा निर्भर हुन्छ, जो फेरि तान्ने संयन्त्र सक्षम हुनमा निर्भर हुन्छन्।

जाँचहरू बन्द गरेर हराएको प्रमाणपत्र सुधार्नु हुँदैन

सन्देश हराओस् भनेर प्रमाणीकरण खुकुलो बनाउने प्रलोभन हुन्छ। त्यसले आफ्नो काम गरिरहेको नियन्त्रण हटाउँछ र अब आफ्नो दाबी प्रमाणित नगर्ने जडान छोड्छ। यदि गेटवेले हालै आफ्नो मूल बदलेको छ, प्रोफाइल सम्पादन गर्नुको सट्टा ग्राहक प्याकेज पुनः डाउनलोड गर्नुहोस्, किनकि पुरानो प्याकेजमा अझै अघिल्लो मूल हुन सक्छ। यदि प्रोफाइल सम्पादकमा प्रमाणपत्र प्रमाणीकरणको विकल्प छैन भने, स्थापित Windows संस्करणले त्यो विधि देखाउँदैन होला; XML हातले सम्पादन गर्नुको सट्टा प्रणाली अद्यावधिक गर्नुहोस्।

प्रमाणपत्र कुन भण्डारमा थियो, कुन प्रयोगकर्ताले ग्राहक चलाए र निजी कुञ्जी थियो वा थिएन भनी लेख्नुहोस्। ती तीनले लगभग हरेक घटना बुझाउँछन्।

पासवर्ड ठीक थियो। विधिलाई साँच्चै चाहिएको प्रमाण अन्तै थियो।