OpenVPN ले प्रोफाइल लोड हुँदा पनि ca.crt भेट्दैन

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

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

प्रोफाइलको बाटो आधार डाइरेक्टरी होइन

/tmp मा सुरु हुने र /etc/vpn/prod/tenant-a.ovpn पाउने प्रक्रियाको कल्पना गर्नुहोस्। त्यो प्रोफाइलभित्र, ca ca.crt लाइनले सापेक्ष बाटो बताउँछ। प्रोफाइल भेटाउने आर्गुमेन्टमा केही पनि त्यो नाम पुनःलेख्दैन, त्यसैले प्रक्रिया /tmp/ca.crt खोज्छ र हराएको फाइल रिपोर्ट गर्छ।

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

म्यानुअलले के छुट्याउँछ: --config र --cd

OpenVPN 2.6 म्यानुअल ले दुई फरक विकल्प वर्णन गर्छ। एउटाले कन्फिगरेसन फाइल लोड गर्छ। अर्कोले कन्फिगरेसन, कुञ्जी, स्क्रिप्ट र अन्य फाइल पढ्नुअघि प्रक्रियाको डाइरेक्टरी बदल्छ, र वर्तमानको कुनै सन्दर्भ नभएको पूर्ण डाइरेक्टरी माग्छ।

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

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

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

सेवा अन्तै सुरु हुन्छ

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

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

दोस्रो आदेशले जीवित प्रक्रियाले वास्तवमा समातेको डाइरेक्टरी देखाउँछ, र र्यापर संलग्न हुँदा यो unit फाइलभन्दा भरपर्दो हुन्छ। दुवै मिलेन भने उत्तर र्यापर हो र unit भ्रामक चिन्ह हो।

खोजपछि: अनुमति, chroot र स्यान्डबक्स

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

तीन सामान्य रूपले एउटै त्रुटि उत्पन्न गर्छन्। फाइल root ले मात्र पढ्न सक्छ, जबकि सेवा त्यो खोल्नुअघि विशेषाधिकार छोड्छ। unit ले प्रोफाइल डाइरेक्टरी समावेश नगर्ने संरक्षात्मक फाइलसिस्टम दृश्य सेट गर्छ। डिमन chroot सँग चल्छ, त्यसैले होस्टमा भएको बाटो त्यो दृश्यभित्र हुँदैन।

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

आफ्नै लन्चले सुधार प्रमाणित गर्नुहोस्

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

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

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

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