क्या OpenConnect में --key-password आपका VPN खाता पासवर्ड है?

विकल्प का नाम शब्दशः पढ़ें। यह एक कुंजी का नाम देता है, और भ्रम तब शुरू होता है जब खोली जाने वाली फ़ाइल को प्रमाणित किए जाने वाले खाते से मिला दिया जाता है। उस विकल्प में खाता पासवर्ड चिपकाएँ और क्लाइंट उससे एक कुंजी फ़ाइल खोलने का प्रयास करेगा, जो ऐसे कारणों से विफल होता है जिनका VPN लॉगिन से कोई संबंध नहीं है।

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

दो रहस्य, दो अलग काम

भूमिकाओं को फ़ाइल पहुँच बनाम नेटवर्क में प्रवेश के रूप में पढ़ें। कुंजी पासवर्ड --sslkey में नामित PEM निजी कुंजी को डिक्रिप्ट करता है ताकि TLS क्लाइंट प्रमाणपत्र प्रस्तुत किया जा सके। यह डिक्रिप्शन स्थानीय रूप से, क्लाइंट प्रक्रिया के भीतर होता है, और पासफ़्रेज़ स्वयं कभी गेटवे तक नहीं जाता। गेटवे जो देखता है वह प्रमाणपत्र और कुंजी से बना हस्ताक्षर है। OpenConnect का मैनुअल --key-password को --certificate और --sslkey के बगल में रखता है, और TPM में रखी कुंजी का उपयोग कर सकने वाले बिल्ड में वही विकल्प इसके बजाय संग्रहण रूट कुंजी का पासवर्ड रखता है।

खाता पासवर्ड प्रकार में भिन्न है। यह प्रमाणीकरण के आदान-प्रदान में जाता है: उपयोगकर्ता नाम और पासवर्ड का फ़ॉर्म, टोकन, SAML राउंड ट्रिप, या कोई संयोजन जिसकी घोषणा गेटवे करता है। कुछ परिनियोजन इसे तब बिल्कुल नहीं माँगते जब प्रमाणपत्र ही एकमात्र कारक हो, और कुछ प्रमाणपत्र के बाद भी माँगते हैं, क्योंकि प्रमाणपत्र उपकरण सिद्ध करता है जबकि खाता व्यक्ति को सिद्ध करता है।

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

कुंजी पासवर्ड वास्तव में कब आवश्यक है

विकल्प का अर्थ केवल तब है जब खोलने के लिए एन्क्रिप्टेड कुंजी हो। यदि आप उपयोगकर्ता नाम और पासवर्ड से और बिना क्लाइंट प्रमाणपत्र के कनेक्ट करते हैं, तो --key-password के पास काम करने के लिए कुछ नहीं है, और इसे जोड़ने से कुछ नहीं बदलता। यदि आप --certificate और --sslkey के साथ कनेक्ट करते हैं, तो कुंजी फ़ाइल का अपना प्रारूप तय करता है कि पासफ़्रेज़ बिल्कुल माँगा जाएगा या नहीं।

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

उपयोगी निदान यह देखना है कि विफलता कब होती है। यदि कोई नेटवर्क प्रमाणीकरण शुरू होने से पहले क्लाइंट रुक जाता है, तो कुंजी फ़ाइल, उसके प्रारूप या पासफ़्रेज़ पर संदेह करें। यदि TLS सत्र स्थापित होता है और फिर गेटवे उपयोगकर्ता को अस्वीकार करता है, तो कुंजी ने अपना काम किया और समस्या खाता आदान-प्रदान में है।

दोनों रहस्यों को शेल इतिहास से बाहर रखें

कमांड-लाइन तर्क अन्य स्थानीय उपयोगकर्ताओं द्वारा प्रक्रिया तालिका के माध्यम से पढ़े जा सकते हैं और अक्सर शेल इतिहास, स्क्रिप्ट और सहायता ट्रांस्क्रिप्ट में कैद हो जाते हैं। OpenConnect --passwd-on-stdin के साथ मानक इनपुट से खाता पासवर्ड पढ़ सकता है, और कुंजी पासफ़्रेज़ तर्क के बजाय इंटरैक्टिव संकेत या एजेंट से आ सकता है। कोई भी तंत्र रहस्य को अपने आप सुरक्षित नहीं बनाता, लेकिन दोनों इसे सबसे अधिक उजागर स्थानों से दूर रखते हैं।

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

निदान आउटपुट ही खामोश रिसाव है। अधिक विस्तृत स्तर पर क्लाइंट लॉग अनुरोध निकाय या विकल्प मान दिखा सकते हैं, और कॉपी किया गया टर्मिनल ट्रांस्क्रिप्ट टिकट में चिपकाना आसान है, इसलिए साझा करने से पहले आउटपुट पढ़ें।

मृत डेस्कटॉप बटन एक अलग खराबी है

जो डेस्कटॉप VPN प्रविष्टि स्पिनर दिखाकर फिर कुछ नहीं करती, वह आमतौर पर प्रमाणीकरण की समस्या ही नहीं है। बटन नेटवर्क प्रबंधक, विक्रेता के एप्लेट या किसी प्लगइन का होता है जो आपकी ओर से OpenConnect चलाता है, और गुम घटक या अपठनीय प्रोफ़ाइल ठीक वही लक्षण पैदा कर सकते हैं। पता लगाएँ कि बटन कौन-सी प्रक्रिया शुरू करता है और क्रेडेंशियल छूने से पहले उसकी त्रुटि पढ़ें।

जब GUI कनेक्ट करने से मना करे तो प्रमाणपत्र सत्यापन ढीला करना या जाँच बंद करना लुभावना लगता है। यह क्लाइंट-एकीकरण की खराबी को सुरक्षा में कमी में बदल देता है और लॉन्च की समस्या शायद ही ठीक करता है। सर्वर सत्यापन अक्षुण्ण रखें, पुष्टि करें कि प्रोफ़ाइल इच्छित गेटवे की ओर इशारा करती है, और जाँचें कि GUI जिस सहायक की अपेक्षा करता है वह वास्तव में स्थापित है।

एक छोटी जाँच-सूची मामलों को अलग करती है। कोई पैकेट निकलने से पहले की स्थानीय विफलता कुंजी या क्लाइंट इंस्टॉल की ओर इशारा करती है। TLS सत्र के बाद गेटवे का अस्वीकार खाता आदान-प्रदान की ओर इशारा करता है। जो बटन कभी क्लाइंट शुरू नहीं करता वह डेस्कटॉप एकीकरण की ओर इशारा करता है। तीन अलग खराबियाँ, जिनमें से एक वह पासवर्ड है जिसे आप गलत बॉक्स में चिपकाने ही वाले थे।