केवल पासवर्ड भएको OpenVPN प्रोफाइलमा कुन CA फाइल जान्छ?

चार प्रश्न क्रममा पूरा गर्नुहोस्, अनि CA संवाद अस्पष्ट रहँदैन। अपरेटरले वास्तवमा कुन सामग्री जारी गरेको थियो, प्रोफाइलमा पहिले नै के छ, कुन फिल्ड सोधिरहेको छ र फाइल लोड भएपछि के हुन्छ? अपरेटरका आफ्नै निर्देशनबाट जवाफ दिन नसकिने पहिलो प्रश्नमा रोकिनुहोस्, किनभने त्यसभन्दा अगाडि अनुमान गर्नु नै सार्वजनिक CA प्रमाणपत्र सर्भरबाट कहिल्यै ननिस्कनु पर्ने निजी कुञ्जीसँग जोडिने बाटो हो।

क्रम महत्त्वपूर्ण छ: अन्तिम दुई प्रश्न कुन सामग्री हुनुपर्छ भन्ने थाहा भएपछि मात्र अर्थपूर्ण हुन्छन्।

प्रोफाइलले पहिले नै के बोकेको छ त्यसबाट सुरु गर्नुहोस्

प्रोफाइललाई टेक्स्ट एडिटरमा खोल्नुहोस् र फाइल खोज्नुअघि ca ब्लक खोज्नुहोस्। अपरेटरको सार्वजनिक CA बोकेको इनलाइन ca ब्लक भनेको प्रोफाइल आत्मनिर्भर छ, र अझै CA फाइल माग्ने क्लाइन्टले अर्को प्रोफाइल वा अपूर्ण आयात पढिरहेको हुन सक्छ। यदि प्रोफाइलमा यसको सट्टा बाटोतर्फ संकेत गर्ने ca लाइन छ भने त्यो बाटो केही एकीकरणमा क्लाइन्टको कार्य निर्देशिकाको सापेक्ष छ र अन्यमा निरपेक्ष। केही बदल्नुअघि तपाईंसँग कुन रूप छ लेख्नुहोस्।

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

प्रोफाइलले सन्दर्भ गर्ने फाइलका लागि दिइएको प्याकेज जाँच्नुहोस्: एक CA प्रमाणपत्र, कहिलेकाहीँ अलग क्लाइन्ट प्रमाणपत्र र कुञ्जी, र सम्भवतः tls-auth वा tls-crypt फाइल। चार फाइलको सन्दर्भ दिने तर दुईसँग आउने प्रोफाइल अपूर्ण हुन्छ, र फिल्डतर्फ संकेत गर्ने कुनै पनि मात्राले त्यो सुधार्दैन। संयोगवश तपाईंसँग भएको प्रमाणपत्र बदल्नुको सट्टा अपरेटरसँग हराएको भाग माग्नुहोस्।

चार प्रकारका सामग्री अलग गर्नुहोस्

CA प्रमाणपत्र सार्वजनिक सामग्री हो जुन सर्भरको पहिचान प्रमाणित गर्न प्रयोग हुन्छ। क्लाइन्ट प्रमाणपत्रले प्रयोगकर्ता वा उपकरणलाई सर्भरसामु चिनाउँछ। निजी कुञ्जी त्यो क्लाइन्ट प्रमाणपत्रको गोप्य आधा हो, र त्यो कहिल्यै CAको हस्ताक्षर कुञ्जी वा सर्भर कुञ्जी हुनु हुँदैन। tls-auth वा tls-crypt सामग्री नियन्त्रण च्यानलको रक्षा गर्ने छुट्टै साझा गोप्य कुरा हो। यी चार विनिमययोग्य छैनन्, र CA फिल्ड क्लाइन्ट प्रमाणपत्रतर्फ फर्काउँदा विश्वासको समस्याजस्तो देखिने प्रमाणीकरण असफलता उत्पन्न हुन्छ।

केवल पासवर्डबाट प्रमाणीकरण ले चारमध्ये कुन चाहिन्छ भन्ने बदल्छ, तिनको अर्थ होइन। auth-user-pass र remote-cert-tls server सँग क्लाइन्टले अझै CAविरुद्ध सर्भर प्रमाणित गर्छ, त्यसैले क्लाइन्ट प्रमाणपत्र नभए पनि CA फिल्ड देखिन्छ। क्लाइन्ट प्रमाणपत्र पनि आवश्यक छ कि छैन अपरेटरको नीतिले निर्धारण गर्छ, र कुनै संवादले तपाईंलाई त्यो बताउन सक्दैन।

क्लाइन्टलाई विश्वास फाइलतर्फ निर्देशित गर्नुहोस्

CA प्रमाणपत्र फाइल आफै चयन गर्नुहोस्, त्यसलाई राख्ने फोल्डर होइन र क्लाइन्ट पहिचान बोक्ने .p12 बन्डल होइन। Windows मा बाटोको वाक्यरचना र फाइल चयनकर्ता अधिकांश मार्गदर्शिकाका Linux उदाहरणभन्दा फरक व्यवहार गर्छन्, त्यसैले स्थापित क्लाइन्टले स्वीकार गर्ने प्रयोग गर्नुहोस् र फाइल त्यो चलाउने खाताले पढ्न सक्छ भनी पुष्टि गर्नुहोस्। अनुमति समस्या र हराएको फाइल संवादमा एउटै देखिन्छ तर फरक लग लाइन बनाउँछ। चयनपछि क्लाइन्टले चयन राखेको पुष्टि गर्न प्रोफाइल सेटिङ फेरि खोल्नुहोस्।

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

यदि क्लाइन्टले इनलाइन ब्लक समर्थन गर्छ भने हातले जोडिएको प्रोफाइलभन्दा अपरेटरको इनलाइन प्रोफाइललाई प्राथमिकता दिनुहोस्। इनलाइन सामग्री प्रोफाइलसँगै यात्रा गर्छ र पुनः आयातमा टिक्छ, जबकि निरपेक्ष बाटो प्रोफाइल अर्को मेसिनमा सर्ने क्षणमै टुट्छ।

उही त्रुटि होइन, अर्को त्रुटि पढ्नुहोस्

सही CA दिनुको उद्देश्य त्रुटि बदल्नु हो, त्यसलाई अदृश्य बनाउनु होइन। CA लोड भएपछिको सर्भर-पहिचान असफलता भनेको प्रमाणपत्र अपेक्षित नाम वा remote-cert-tls अपेक्षासँग मिलेन, जुन पासवर्ड अस्वीकारभन्दा फरक मर्मत हो। पासवर्ड अस्वीकार भनेको TLS तह सफल भयो र प्रमाणहरू गलत छन्। पहिलो नयाँ सन्देश राख्नुहोस्; त्यही उपयोगी हुन्छ।

जोडिने तर कतै नपुग्ने क्लाइन्ट विश्वास पूरै पार गरिसकेको छ र अब राउटिङ वा DNS प्रश्नको सामना गरिरहेको छ।

त्यो संवाद पार गर्न कहिल्यै प्रमाणीकरण बन्द नगर्नुहोस्। कुनै पनि प्रमाणपत्र स्वीकार गर्ने क्लाइन्टसँग CA माग्ने कारण हुँदैन, र त्यसले बनाउने टनेल अपरेटरको इच्छित टनेल होइन।