क्लाइंट प्रमाणपत्र के बिना 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 अक्सर साथ में सक्षम होता है, और वह उस पहचान को बदलता है जिसे बाद के कॉलबैक और प्रति-क्लाइंट कॉन्फ़िगरेशन फ़ाइलें देखती हैं। वह पासवर्ड सत्यापित नहीं करता, और अपात्र खाते को पात्र नहीं बनाता। ये अलग काम हैं, और इन्हें मिलाना ही वह तरीका है जिससे कोई माइग्रेशन अपनी सुखद-पथ परीक्षा पास करता है और अपनी पहली वास्तविक घटना में विफल होता है।

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

नीति, प्रोफ़ाइल और मैपिंग एक साथ बदलें

तीन चीज़ों का समन्वय करें: सर्वर निर्देश, क्लाइंट प्रोफ़ाइल, और प्रति-क्लाइंट पहचान मैपिंग। इन्हें अलग-अलग बदलें तो क्लाइंट सत्यापन से पहले विफल होते हैं, या ऐसे नाम से जुड़ते हैं जिसकी व्यवस्थापक को अपेक्षा नहीं थी, जो अधिक बुरा है क्योंकि वह सफलता जैसा दिखता है। गलत पहचान के अंतर्गत सफल होने वाला कनेक्शन विफल होने वाले से अधिक कठिनाई से ध्यान में आता है।

इस पथ के लिए दो परीक्षण खाते रखें, एक वैध और एक ज्ञात-खराब, और सत्यापनकर्ता में किसी भी बदलाव के बाद दोनों का उपयोग करें। वैध खाता सुखद पथ और पहचान मैपिंग साबित करता है; खराब वाला साबित करता है कि अस्वीकृति अब भी काम करती है। कोई भी परीक्षण आपको पात्रता नियमों के बारे में कुछ नहीं बताता, इसलिए यदि परिनियोजन में ऐसे नियम हों तो नीतिगत कारणों से अस्वीकार किया जाने वाला खाता जोड़ें। हर बदलाव के बाद तीनों चलाएँ, क्योंकि सब कुछ स्वीकार करने लगा सत्यापनकर्ता बिल्कुल काम करने वाले लॉगिन जैसा दिखता है।

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