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 ओळीशी जुळतो, तर शोध काम करून झाला. जर क्लायंट अजूनही सामान्य पूलमध्ये पडतो, तर लॉग ओळींच्या मोजणीकडे परत जा: शून्य आयात म्हणजे मार्ग किंवा ओळख चुकीची, चुकीच्या सामग्रीसह एक आयात म्हणजे तुम्ही डेमॉन वाचतो त्यापेक्षा वेगळी फाइल संपादित करत आहात.

आधीचे युनिट आणि कॉन्फिग एकत्र पुनर्संचयित करून मागे फिरा, नंतर रीस्टार्ट करा. यापैकी कशासाठीही प्रमाणपत्रे पुन्हा देण्याची गरज नाही, आणि डिरेक्टरीची समस्या क्रेडेन्शियलची समस्या मानणे हाच पाच मिनिटांची दुरुस्ती देखभाल विंडोमध्ये बदलण्याचा मार्ग आहे.