क्लायंट प्रमाणपत्राशिवाय OpenVPN: सर्व्हर धोरण, प्रोफाइल नाही

तुम्ही प्रमाणपत्र आणि की च्या ओळी पुसता, प्रोफाइल सुपूर्द करता, आणि कनेक्शन अजूनही प्रमाणपत्र त्रुटीने अयशस्वी होते। प्रोफाइल कधीच ती मागणी लागू करणारी गोष्ट नव्हती। क्लायंट प्रमाणपत्र अनिवार्य आहे की नाही हे सर्व्हर ठरवतो, आणि क्लायंटच्या बाजूचे कोणतेही संपादन बोलणी करून ते रद्द करत नाही। त्यामुळे उपाय म्हणजे सर्व्हर धोरणातील बदल, जाणीवपूर्वक केलेला, आणि त्यावर अवलंबून असलेले सर्व त्याच टप्प्यात अद्ययावत केले जाते।

प्रोफाइल हे धोरण नाही

Community OpenVPN 2.6 अनिवार्य क्लायंट प्रमाणपत्रांसह येते, कारण verify-client-cert डीफॉल्टनुसार require आहे। ते none वर सेट करणे हेच प्रमाणपत्राची मागणी थांबवते आणि क्लायंट प्रमाणीकरण सर्व्हर आधीच चालवत असलेल्या वापरकर्तानाव आणि पासवर्ड व्यवस्थेकडे सोपवते। जुन्या मार्गदर्शकांमध्ये त्याच कल्पनेच्या जुन्या शुद्धलेखनाचा client-cert-not-required वापरला जातो, म्हणून तुमची स्थापित आवृत्ती जे निर्देश दस्तऐवजीकरण करते ते वापरा। कोणत्याही प्रकारे बदल सर्व्हरवर होतो, आणि कोणतेही क्लायंट प्रोफाइल तो करू शकत नाही।

खालील तुकडा सर्व्हरच्या बाजूचा संपूर्ण बदल आहे, आणि तो एकटाच कार्यरत प्रमाणीकरण संरचना नाही। verify-client-cert none प्रमाणपत्राची मागणी काढून टाकते, तर username-as-common-name खात्याचे नाव पुढील कॉलबॅक आणि प्रत्येक क्लायंटच्या फाइल्स पाहतात ती ओळख बनवते। कोणतीही ओळ पासवर्ड तपासत नाही, त्यामुळे पडताळणीकर्ता अजूनही असणे आवश्यक आहे।

verify-client-cert none
username-as-common-name

तो पडताळणीकर्ता auth-user-pass-verify द्वारे चालवला जाणारा प्लगइन किंवा स्क्रिप्ट आहे, आणि वरीलपैकी कोणतीही ओळ अर्थपूर्ण होण्यापूर्वी तो त्याच्या जागी असणे आवश्यक आहे। क्रम उलटल्यास सर्व्हर कोणतेही प्रमाणपत्र मागत नाही आणि कोणतेही खाते तपासत नाही असे खिडकी मिळते।

सर्व्हरची पडताळणी अजून काय करते

क्लायंट प्रमाणपत्र सोडणे म्हणजे TLS सोडणे नाही। सर्व्हर आपले प्रमाणपत्र आणि की ठेवतो, आणि क्लायंट CA विश्वास आणि होस्टनाव तपासण्या ठेवतो ज्या त्याला बनावट व्यक्तीशी बोलण्यापासून रोखतात। क्लायंटकडे आता प्रमाणपत्र नाही म्हणून remote-cert-tls server किंवा CA बंडल काढणे हे सामान्य आणि गंभीर चुकीचे वाचन आहे, आणि 2.6 संदर्भ स्पष्ट सांगतो की दोन्ही दिशा स्वतंत्र आहेत। एक सर्व्हर क्लायंटसमोर सिद्ध करते; दुसरी सर्व्हरसमोर क्लायंट सिद्ध करते।

प्रोफाइल tls-auth किंवा tls-crypt ब्लॉकही ठेवू शकते। ती स्वतःच्या वितरण आणि फिरण्याच्या चक्रासह सामायिक नियंत्रण-चॅनेल की आहे, त्यामुळे प्रमाणपत्र किंवा की च्या ओळींशिवाय फाइल आपोआप प्रकाशित करण्यास सुरक्षित नाही। तुम्ही ती वाचेपर्यंत ती गुप्त म्हणून हाताळा।

कार्यरत प्रोफाइलमधून कॉपी केलेली प्रमाणपत्र फाइल स्वतःच काहीही सिद्ध करत नाही; मालकी म्हणजे तिच्याशी जुळणारी खाजगी की ठेवणे, जी प्रमाणपत्र-प्रमाणीकृत तैनाती तपासते। प्रमाणपत्र असलेली फाइल ही त्याद्वारे प्रमाणीकरण करता येणारी फाइल नाही।

पडताळणीकर्त्याने काय करावे

प्रमाणपत्राची मागणी काढून टाकल्यानंतर सर्व काही पडताळणीकर्त्यावर अवलंबून आहे: प्लगइन, किंवा auth-user-pass-verify द्वारे चालवली जाणारी स्क्रिप्ट। त्याने अवैध क्रेडेन्शियल्स नाकारली पाहिजेत, अक्षम किंवा अपात्र खाती नाकारली पाहिजेत, आणि त्याच्या बॅकएंडपर्यंत पोहोचू शकत नसेल तेव्हा बंद होऊन अयशस्वी व्हावे। username-as-common-name बहुतेकदा सोबत सक्षम केले जाते, आणि ते पुढील कॉलबॅक आणि प्रत्येक क्लायंटच्या संरचना फाइल्स पाहतात ती ओळख बदलते। ते पासवर्ड तपासत नाही, आणि अपात्र खात्याला पात्र बनवत नाही। ही स्वतंत्र कामे आहेत, आणि ती एकत्र करणे हाच मार्ग आहे ज्यामुळे स्थलांतर आपली सुखद-मार्ग चाचणी उत्तीर्ण होते आणि पहिल्या वास्तविक घटनेत अयशस्वी होते।

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

धोरण, प्रोफाइल आणि मॅपिंग एकत्र बदला

तीन गोष्टींचे समन्वय साधा: सर्व्हर निर्देश, क्लायंट प्रोफाइल, आणि प्रत्येक क्लायंटची ओळख मॅपिंग। त्या वेगळ्या बदलल्या तर क्लायंट पडताळणीपूर्वीच अयशस्वी होतात, किंवा व्यवस्थापकाला अपेक्षित नसलेल्या नावाने जोडले जातात, जे अधिक वाईट कारण ते यशासारखे दिसते। चुकीच्या ओळखीखाली यशस्वी होणारे कनेक्शन अयशस्वी होणाऱ्यापेक्षा लक्षात घेणे कठीण आहे।

या मार्गासाठी दोन चाचणी खाती ठेवा, एक वैध आणि एक ज्ञात-वाईट, आणि पडताळणीकर्त्यातील कोणत्याही बदलानंतर दोन्ही वापरा। वैध खाते सुखद मार्ग आणि ओळख मॅपिंग सिद्ध करते; वाईट खाते नकार अजूनही कार्यरत आहे हे सिद्ध करते। कोणतीही चाचणी तुम्हाला पात्रता नियमांबद्दल काहीही सांगत नाही, म्हणून तैनातीत असे नियम असल्यास धोरणात्मक कारणांनी नाकारले जावे असे खाते जोडा। प्रत्येक बदलानंतर तीनही चालवा, कारण सर्व काही स्वीकारू लागलेला पडताळणीकर्ता कार्यरत लॉगिनसारखाच दिसतो।

सर्व्हर प्रत्यक्षात कोणत्या प्रमाणीकरण पद्धती स्वीकारतो ते नोंदवा, प्रोफाइल ज्या सुचवते त्या नाही। ती नोंद लोक सतत विचारतात त्या प्रश्नाचे उत्तर देते, तो म्हणजे या सेवेशी कोण जोडले जाऊ शकते। ती पुढील व्यवस्थापकापेक्षाही जास्त टिकते, जो अन्यथा ती पॅकेट कॅप्चरमधून पुन्हा शोधून काढेल।