कुन 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 निर्देशिका ले प्रमाणीकरणले इन्स्टल गरिएका फाइलहरूलाई स्थानीय रूपमा अभिलेख गरिएको मेटाडेटासँग तुलना गर्छ, जहाँ छ त्यहाँ सुरक्षित चेकसम प्रयोग गर्छ भनी अभिलेख गर्छ। यसले बदलिएको प्याकेज फाइल देख्छ, र यसको सट्टा अर्को बाइनरी चलिरहेको छ कि भनी बताउन सक्दैन।

मर्मतअघि अवस्था अभिलेख गर्नुहोस्

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

पढ्नुअघि र्यापरको सामग्री सहायता थ्रेडमा टाँस्नु हुँदैन, किनकि यी स्क्रिप्टहरूले कहिलेकाहीँ प्रमाणहरू वा गेटवे विवरण बोक्छन्।

काम गर्दा सेवाले कुन प्रोफाइल प्रयोग गर्छ र को जोडिएको छ अभिलेख गर्नुहोस्, किनकि सुरुङ पुनः सुरु गर्दा तपाईंले होस्ट प्रशासन गरिरहेको सत्र अवरुद्ध हुन सक्छ।

लन्च प्रमाणित गर्नुहोस्, त्यसपछि र्यापर हटाउनुहोस्

मर्मतपछि सेवा सुरु गर्नुहोस् र प्रक्रिया तपाईंले चाहेको पथमा चलिरहेको पुष्टि गर्नुहोस्। हातले चलाइएको संस्करण प्रश्नले फाइल काम गर्छ भनी प्रमाणित गर्छ; युनिटले त्यसैलाई प्रयोग गर्छ भनी प्रमाणित गर्दैन।

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

स्थानान्तरित र्यापरलाई त्यसै परिवर्तन-अभिलेखमार्फत हटाउनुहोस् जसले यसलाई ल्यायो। सकिएको मर्मतले कुन कार्यान्वयनयोग्य फाइल चल्छ, किन, र कुन फाइल हटाइयो भनी बताउँछ; फाइलको नाम पुनःस्थापित गरेर आशा गर्नु त्यो होइन।