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

मार्ग लोडिंग यशस्वी झाल्यावरही प्रमाणीकरण आणि मार्गनिर्देशन हे स्वतःच्या अयशस्वीतेसह वेगळे टप्पे आहेत, आणि जोडणी उठूनही वाहतूक न पुरवणे ही वेगळी चौकशी आहे. इथली दुरुस्ती फाइल्या कोणत्या डिरेक्टरीतून आल्या एवढीच आहे, आणि ती कॉलमध्ये दिसायला हवी, शेवटी हाताने चालवणाऱ्याच्या स्मरणात राहण्याऐवजी.

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