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

नकारात्मक अवस्थाहरूलाई सकारात्मक अवस्थाइतिकै होसियारीसाथ परीक्षण गर्नुहोस्। पासवर्ड सोध देखाउने प्रोफाइलले ग्राहकले सोध कोर्न सक्छ भन्ने मात्र प्रमाणित गर्छ, जबकि गलत पासवर्ड स्वीकार गर्ने सर्भरले अझ नराम्रो कुरा प्रमाणित गर्छ। परीक्षण समूहमा खराब पासवर्ड मात्र होइन, निष्क्रिय खाता र म्याद सकिएको प्रमाण पनि थप्नुहोस्।

नीति, प्रोफाइल र म्यापिङ सँगै बदल्नुहोस्

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

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

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