के 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 सत्रपछि गेटवेको अस्वीकार खाता आदानप्रदानतर्फ सङ्केत गर्छ। क्लाइन्ट कहिल्यै सुरु नगर्ने बटन डेस्कटप एकीकरणतर्फ सङ्केत गर्छ। तीन फरक खराबी, जसमध्ये एउटा तपाईंले गलत बाकसमा टाँस्न लागेको पासवर्ड हो।