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 सत्रानंतर गेटवेचा नकार खाते देवघेवीकडे निर्देश करतो. क्लायंट कधीही सुरू न करणारे बटण डेस्कटॉप एकात्मतेकडे निर्देश करते. तीन वेगळे दोष, त्यातील एक तुम्ही चुकीच्या खोक्यात पेस्ट करणार होता तो पासवर्ड.