कोणती openvpn बायनरी चालू आहे? लाँच पथ तपासा

जुन्या उपायाने OpenVPN ची अंमलबजावणी-योग्य फाइल दुसरीकडे हलवली आणि मूळ पथावर shell रॅपर सोडला। काही महिन्यांनी अपग्रेड येते, आणि तो उपाय पूर्ववत करणे हे कोणती फाइल खरी क्लायंट आहे याचा अंदाजाचा खेळ बनते। आदेशाचे नाव, सेवेमध्ये संरचित केलेली अंमलबजावणी-योग्य फाइल आणि पॅकेजची स्वतःची फाइल यादी या सर्व वेगवेगळ्या वस्तूंकडे निर्देश करू शकतात, आणि बाकीच्यांशिवाय एक दुरुस्त करणे असे होस्ट तयार करते जे दुरुस्त दिसते पण अधिक वाईट वागते।

सेवा जो पथ सुरू करते त्यापासून सुरुवात करा

टर्मिनल आणि systemd युनिट अंमलबजावणी-योग्य फाइलींचे निराकरण एकाच पद्धतीने करत नाहीत। shell PATH मध्ये शोधते; युनिट पथाचे नाव देते, आणि drop-in ओव्हरराइड तुम्ही वाचत असलेल्या फाइलला न स्पर्श करता तो बदलू शकतात। हाच फरक या कामातील बहुतेक गोंधळ स्पष्ट करतो। तुमच्या दुरुस्तीने कोणत्या फाइलला लक्ष्य करावे हेदेखील तोच ठरवतो।

युनिटला ते काय चालवते विचारा, ते बदलणाऱ्या drop-in सह, आणि तुम्ही अधिकृत मानत असलेल्या तुकड्याऐवजी परिणामी ExecStart ओळ वाचा। नंतर तो पथ कोणत्याही प्रतीकात्मक दुव्यातून अंतिम फाइलपर्यंत अनुसरा। लपलेल्या डिरेक्टरीत exec ने संपणारा रॅपर या जुन्या उपायांची नेहमीची रचना आहे।

काहीही बदलण्यापूर्वी निराकरण केलेला पथ लिहून ठेवा।

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

आदेशाच्या नावाची सेवेच्या पथाशी तुलना करा

दोन्ही उत्तरे अनेकदा वेगळी असतात, आणि तो फरक आपोआप दोष नाही। NetworkManager प्लगइन स्वतःचा पथ सुरू करू शकते, आणि कंटेनर दुसरा माउंट करू शकतो।

महत्त्वाचे म्हणजे रहदारीला सेवा देणारी प्रक्रिया कोणता मालक सुरू करतो हे जाणणे। जर युनिट /usr/local/sbin/openvpn-wrapper चालवत असेल आणि तुमचा shell /usr/sbin/openvpn निराकरण करत असेल, तर दुसरी फाइल दुरुस्त केल्याने सेवेत काहीही बदलत नाही।

प्रत्येक उमेदवार कोणत्या पॅकेजचा आहे ते विचारा, नंतर फाइल पॅकेज-व्यवस्थित आहे की स्थानिकरित्या ठेवली आहे हे ठरवा। मालक पॅकेज नसलेली फाइल ही कोणीतरी जाणूनबुजून तिथे ठेवलेली फाइल आहे, आणि ती हटवण्यापूर्वी नाव, मालक आणि कारणास पात्र आहे। उलटी चूकही सामान्य आहे: फोरम पोस्टने तीच डिरेक्टरी वापरल्यामुळे जुन्या साठवलेल्या बायनरीने पॅकेज फाइल ओव्हरराइट करणे।

पॅकेज फाइलींबद्दल पॅकेज डेटाबेसला बोलू द्या

जेव्हा सॉफ्टवेअर Debian पॅकेजमधून आले असेल, तेव्हा पॅकेज डेटाबेस तुम्हाला सांगू शकतो की त्याच्या फाइलीं अजूनही इन्स्टॉल केलेल्याशी जुळतात का। हा अखंडतेचा मर्यादित प्रश्न आहे, सुरक्षेचा निवाडा नाही, आणि काय दुरुस्त करायचे हे ठरवताना हा फरक महत्त्वाचा आहे। जुळत नसणे म्हणजे फाइल इन्स्टॉलनंतर बदलली, जी तुमची जुनी युक्ती किंवा वैध स्थानिक संपादन असू शकते। आउटपुट कोणते हे ठरवत नाही, म्हणून ते निष्कर्ष नव्हे तर संकेत म्हणून वाचा।

पडताळणी चालवा आणि रिकाम्या निकालाला कशाचाही पुरावा मानण्याऐवजी आउटपुट वाचा।

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

dpkg मॅन्युअल नोंदवते की पडताळणी इन्स्टॉल केलेल्या फाइलींची स्थानिकरित्या नोंदवलेल्या मेटाडेटाशी तुलना करते, जिथे असेल तिथे साठवलेल्या चेकसमचा वापर करते। ती बदललेली पॅकेज फाइल लक्षात घेते, आणि तिच्या जागी दुसरी बायनरी चालू आहे का हे ती सांगू शकत नाही।

दुरुस्तीपूर्वी स्थिती नोंदवा

निराकरण केलेला लाँच पथ, फाइलचा पॅकेजशी संबंध, रॅपरचे स्थान आणि तो आणणारा बदल-नोंद गोळा करा। जर रॅपरमध्ये नंतर आवश्यक असलेले एकत्रीकरणाचे काम असेल तर तो सुरक्षित जागी कॉपी करा।

वाचण्यापूर्वी रॅपरची सामग्री सहाय्य थ्रेडमध्ये पेस्ट करू नका, कारण या स्क्रिप्ट कधीकधी ओळखपत्रे किंवा गेटवेचे तपशील घेऊन जातात।

काम करताना सेवा कोणती प्रोफाइल वापरते आणि कोण जोडलेले आहे हे नोंदवा, कारण बोगदा पुन्हा सुरू केल्यास तुम्ही होस्ट व्यवस्थापित करत असलेले सत्र खंडित होऊ शकते।

लाँचची पडताळणी करा, नंतर रॅपर काढून टाका

दुरुस्तीनंतर सेवा सुरू करा आणि प्रक्रिया तुम्ही हेतू ठेवलेल्या पथावर चालू असल्याची खात्री करा। हाताने चालवलेली आवृत्ती-चौकशी फाइल कार्यरत आहे हे सिद्ध करते; युनिट ती वापरते हे सिद्ध करत नाही।

नंतर क्लायंट पुन्हा जोडा आणि प्रोफाइल अजूनही प्रमाणीकरण करते का ते तपासा, कारण मूळ पर्याय दुर्लक्षित करणारी बायनरी अदलाबदल प्रमाणपत्राच्या समस्येसारखी दिसणाऱ्या पद्धतीने अयशस्वी होईल।

स्थलांतरित झालेला रॅपर तो आणणाऱ्या त्याच बदल-नोंदीद्वारे काढून टाका। पूर्ण झालेली दुरुस्ती कोणती अंमलबजावणी-योग्य फाइल चालू आहे, का, आणि कोणती फाइल काढली हे सांगते; फाइलचे नाव पुनर्संचयित करून आशा धरणे हे तसे नाही।