OpenVPN ले प्रमाणपत्र र कुञ्जी कसरी समाधान गर्छ: इनलाइन PEM वा फाइल पथ

सन्देशले OpenVPN ले इनलाइन प्रमाणपत्र लोड गर्न सक्दैन भन्छ, तर तपाईंको दिमागमा भएको फाइल नामले उल्टो भन्छ। पार्सरले के पायो भन्ने फाइल प्रणालीमा के छ भन्नेभन्दा बढी महत्त्वपूर्ण छ, किनकि cert निर्देशनले पूर्ण रूपमा फरक दुई प्रकारका मान स्वीकार गर्छ। एउटा त्यो खोल्ने पथ हो; अर्को कन्फिगरेसनभित्र आएको PEM पाठ हो। चलिरहेको क्लाइन्टले कुन रूप पायो भन्ने थाहा नभएसम्म हरेक सुधार एक अनुमान हो।

दुई भण्डारण रूप, एउटा निर्देशन

cert, key र ca निर्देशनहरूले प्रत्येकले पथ वा इनलाइन ब्लक स्वीकार गर्छन्। मान पथ भएमा OpenVPN ले त्यो फाइल खोल्छ र डिस्कबाट वस्तु पढ्छ। कन्फिगरेसनमा cert ट्यागले घेरिएको ब्लक भएमा त्यही निर्देशनले त्यसको सट्टा ती ट्यागहरूबीचको सामग्री प्रयोग गर्छ, र कुनै छुट्टै फाइल संलग्न हुँदैन।

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

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

इनलाइन ब्लक कसरी वस्तु बन्छ

इनलाइन सामग्री कन्फिगरेसनबाट निकालिन्छ र पाठको रूपमा PEM पार्सरलाई दिइन्छ। त्यो पार्सरले सामान्य सीमाहरू अपेक्षा गर्छ: BEGIN लाइन, base64 पेलोड र मिल्ने END लाइन। ब्लक असफल प्रतिलिपिले काटिएको भए, डाउनलोड पृष्ठले त्यसलाई HTMLमा बेरेको भए, वा ड्यासहरू सामान्य बनाउने एडिटरमा खोलिएको भए, पार्सर अवस्थित देखिने सामग्रीमा असफल हुन्छ।

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

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

लोड भएको प्रोफाइलले वास्तवमा कुन रूप प्रयोग गर्छ जाँच्नुहोस्, तपाईंको एडिटरले संयोगवश कुन फाइल खोल्यो होइन:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

पथ सन्दर्भ कसरी समाधान हुन्छ

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

सापेक्ष पथहरूले त्यही अस्पष्टता उत्तराधिकारमा पाउँछन्। खाली फाइल नाम देख्दा, तपाईंको टर्मिनलसँग मिल्छ भनी मान्नुको सट्टा उत्पादनमा प्रक्रियाको हालको निर्देशिका के हो सोध्नुहोस्।

छुट्टै भण्डारण गरिएको प्रमाणपत्रका लागि, त्यसमाथि केही डिबग गर्नु अघि अफलाइन पार्सले वस्तु पुष्टि गर्छ:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

ती आदेशहरूले फाइलहरू पढ्न योग्य र संरचनात्मक रूपमा वैध छन् भनी प्रमाणित गर्छन्। तीले सहकर्मीले जारीकर्तामाथि विश्वास गर्छ, प्रमाणपत्र अझै आफ्नो वैधता अवधिभित्र छ, वा कुञ्जी त्यसैको हो भनी प्रमाणित गर्दैनन्।

पार्सर त्रुटिले के भन्न सक्छ र के भन्न सक्दैन

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

पार्स सफल भएपछि, अर्को असफलता पछिको चरणको हुन्छ। विश्वास अस्वीकृति, उद्देश्यको बेमेल वा कुञ्जीको बेमेल लोडरले होइन, सहकर्मी वा TLS तहले रिपोर्ट गर्छ। एउटै फाइल बारम्बार बदल्दा त्यो त्रुटि सर्दैन।

अनुसन्धानका क्रममा संवेदनशील आधा भाग सार्वजनिक प्रतिवेदनबाहिर राख्नुहोस्। निर्देशनहरूका नाम, त्रुटिको पाठ र ब्लकको संरचना साझा गर्नुहोस्, कुञ्जी सामग्री र कुनै पनि पहिचान गर्ने पेलोड हटाएर। openvpn(8) पुस्तिका फाइल निर्देशनहरूका दुवै रूप र तिनका पछाडिको कार्य-निर्देशिका व्यवहारको दस्तावेजीकरण गर्छ।