OpenVPN सेवा बनेपछि client-config-dir बेवास्ता गरिन्छ

तपाईंको टनेल उठ्छ र क्लाइन्ट जोडिन्छ, तर स्थिर ठेगाना र त्यो एक प्रयोगकर्ताका लागि तपाईंले परिभाषित गरेका धकेलिएका मार्ग हराएका छन्। लगमा “file not found” लेखिएको छैन, र यसैले मानिसहरूलाई प्रमाणपत्र फेरि बनाउन पठाउँछ। यस्ता अधिकांश अवस्थामा डेमोन तपाईंले परीक्षण गरेको शेलभन्दा फरक सूचीबाट चल्छ, र client-config-dir तपाईंले अनुमान गरेजस्तो कहिल्यै समाधान भएन। सुधार मार्गको सुधार हो, प्रमाणहरू रिसेट गर्नु होइन।

कन्फिग छुनुअघि युनिट पढ्नुहोस्

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

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

खाली WorkingDirectory भन्नाले युनिट / मा सुरु हुन्छ, त्यसैले सापेक्ष client-config-dir ccd /ccd मा खोजिन्छ। त्यो सूची लगभग कहिल्यै हुँदैन, र डेमोनले त्यसको अनुपस्थितिलाई घातक मान्दैन।

यसलाई परीक्षणका बेला प्रयोग गरेको अन्तरक्रियात्मक सुरुवातसँग तुलना गर्नुहोस्, जहाँ तपाईंको शेलको हालको सूची सम्भवतः कन्फिग सूची थियो। उही फाइल, उही किवर्ड, दुई फरक नतिजा।

सापेक्ष मार्ग केको सापेक्ष समाधान गरिन्छ

किवर्ड विकल्प प्रयोग गरिने क्षणमा प्रक्रियाको कार्य सूचीको सापेक्ष समाधान गरिन्छ। यसको अर्थ “मैले --config सँग पठाएको कन्फिग फाइलको छेउमा” होइन। OpenVPN पूर्ण मार्गबाट कन्फिग पढ्न खुसी हुन्छ र सापेक्ष मानहरू अझै अन्तै समाधान गर्छ, र यहीँ ठ्याक्कै जाल छ। OpenVPN 2.6 को पुस्तिका नियम --client-config-dir मुनि र फेरि --cd मुनि बताउँछ।

cd किवर्डले अन्य फाइल पढ्नुअघि त्यो सन्दर्भ बदल्छ, त्यसैले cd /etc/openvpn/server सेट गरेर त्यसपछि client-config-dir ccd राख्ने युनिट /etc/openvpn/server/ccd मा समाधान हुन्छ। यदि तपाईं cd थप्नुहुन्छ भने, निर्देशनहरूको क्रम जाँच्नुहोस् र यो उही फाइलका हरेक अन्य सापेक्ष सन्दर्भमा असर गर्छ भन्ने सम्झनुहोस्।

डेमोनको खाताको रूपमा मार्ग हिँड्नुहोस्

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

namei ले हरेक घटकको अनुमति क्रममा छाप्छ, जुन सूचीहरू एक-एक गरेर जाँच्नभन्दा छिटो हुन्छ:

namei -l /etc/openvpn/server/ccd/client1

त्यसपछि पढाइलाई आफ्नो रूपमा होइन, सेवा खाताको रूपमा जाँच्नुहोस्:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

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

अनुमान नगरी खोजी पुष्टि गर्नुहोस्

एक पटक पुनः सुरुका लागि लग स्तर बढाउनुहोस् र क्लाइन्ट-विशेष विकल्पबारे सर्भर के भन्छ पढ्नुहोस्। verb 4 मा डेमोनले आयात गरेको प्रति-क्लाइन्ट कन्फिग रिपोर्ट गर्छ, त्यसैले अनुपस्थित लाइन त्यो जडानका लागि कुनै फाइल नपढिएको प्रत्यक्ष प्रमाण हो।

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

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

कुनै फाइल नमिल्दा के हुनुपर्छ निर्णय गर्नुहोस्। ccd-exclusive बिना क्लाइन्टलाई विश्वव्यापी पूल सेटिङसँग मात्र स्वीकार गरिन्छ, र यही माथि वर्णन गरिएको मौन असफलता हो। यससँग अनुपस्थित फाइल अस्वीकृत जडान बन्छ, र त्यो अस्वीकृति देख्न सजिलो तर भारमुनि डिबग गर्न गाह्रो हुन्छ।

सुधार्नुहोस्, पुनः सुरु गर्नुहोस्, प्रमाणित गर्नुहोस्

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

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

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

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