सही 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 हाथ से संपादित करने के बजाय सिस्टम अपडेट करें।

लिख लें कि किस स्टोर में प्रमाणपत्र था, किस उपयोगकर्ता ने क्लाइंट चलाया और निजी कुंजी मौजूद थी या नहीं। ये तीन लगभग हर मामला समझाते हैं।

पासवर्ड ठीक था। विधि को वास्तव में जिस क्रेडेंशियल की ज़रूरत थी वह कहीं और था।