VPN क्लाइन्ट अनइन्स्टल भयो, तैपनि बुटमा टनेल सुरु हुन्छ

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

अनइन्स्टलरले कहिल्यै नलेखेको कुरा

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

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

चार मालिक, पहिले पढाइ मात्र

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

dpkg -l | grep -i acmevpn
systemctl list-unit-files | grep -i acmevpn
systemctl list-units --type=service --state=running | grep -i acmevpn

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

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show --active
grep -ril acmevpn /etc/apt/sources.list.d/ /etc/apt/sources.list

सफाइपछि पनि जीवित प्रक्रिया या त सक्रिय युनिट हो या अर्को प्रोग्रामको सन्तान। अब नभएको सेवालाई दोष दिनुअघि प्रक्रिया तालिका र त्यसको अभिभावक शृंखला पढ्नुहोस्। प्रति-प्रयोगकर्ता अटोस्टार्ट प्रविष्टिलाई पनि त्यही जाँच चाहिन्छ, र ती केवल नयाँ लगइन शेलमा देखिन्छन्, root सत्रमा होइन।

आपसमा बदल्न नसकिने तीन क्रियापद

रोक्ने कामले हालको दौड अन्त्य गर्छ, अक्षम गर्नेले बुट-समयका लिङ्क हटाउँछ, र मास्किङले युनिटलाई /dev/null तर्फ निर्देश गर्छ। तेस्रोले मात्र सकेट, टाइमर वा निर्भरतामार्फत सक्रियतालाई पनि रोक्छ, जसले यसलाई तीनमध्ये सबैभन्दा बलियो बनाउँछ। मेसिनसँग के गर्ने भनेर अझै निर्णय गर्दै गर्दा क्रम महत्त्वपूर्ण हुन्छ। त्यो निर्णयका क्रममा मास्किङ सही अवस्था हो, किनकि यो अर्को बुटमा चुपचाप सुरु हुनुको सट्टा ठूलो स्वरमा असफल हुन्छ।

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

वाइल्डकार्डले गलत प्रोफाइल हटाइन्छ

तपाईंले लेखेको UUID ले प्रोफाइल हटाउनुहोस्, र कहिल्यै वाइल्डकार्डले होइन। keyfile डाइरेक्टरीमा मेसिनका सबै Wi-Fi र Ethernet प्रोफाइल पनि हुन्छन्, त्यसैले फराकिलो मिलानले तपाईंलाई अझै चाहिने कुरा हटाइदिन्छ। हातले हटाइएको keyfile लाई जुन नीतिको मालिक हो त्यसले फेरि बनाउन सक्छ, जसले हटाउने कामलाई अप्रभावी देखाउँछ।

nmcli connection delete uuid <uuid>

यदि त्यो प्रोफाइल तपाईंसँग बाँकी एक मात्र प्रतिलिपि हो भने पहिले गेटवे र पहिचान निर्यात गर्नुहोस्, किनकि स्थानीय हटाइले सर्भरमा केही रद्द गर्दैन। भण्डारले पनि त्यही नियम पालना गर्छ: एक मात्र विक्रेता फाइल र त्यसको किरिङ हटाउनुहोस्, त्यसपछि प्याकेज सूची रिफ्रेस गर्नुहोस् र तपाईंले साँच्चै चाहेको इन्स्टलेसन फेरि प्रयास गर्नुहोस्। पुरानो तेस्रो-पक्ष प्रविष्टि राख्दा पुरानो निर्भरता पिन हुन सक्छ वा जवाफ नै नआउन सक्छ। दुवै हटाइ साना छन्, र तपाईंले राखेको प्रतिबाट जुनसुकै फर्काउन सकिन्छ।

रिबुटपछि अझै के चल्छ

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

ip link
ip route
resolvectl status

नयाँ लगइन शेल पनि खोल्नुहोस्, किनकि अटोस्टार्ट प्रविष्टि त्यहीँ मात्र सक्रिय हुन्छ। त्यसपछि इन्टरफेसको स्थिति बदल्दा हरेक पटक कनेक्शन माथि ल्याउने स्क्रिप्टका लागि /etc/NetworkManager/dispatcher.d/ पढ्नुहोस्, जसले पछाडि सेवा नहुँदा पनि टनेल फर्केर आउने कुरा व्याख्या गर्छ। अझै केही बाहिर डायल गर्दै छ भने लक्षण नरोकिएसम्म फाइल हटाउनुभन्दा प्रक्रियालाई त्यसको अभिभावकसम्म पछ्याउनुहोस्। मेसिन सफा गर्ने र खाता रद्द गर्ने छुट्टाछुट्टै काम रहन्छन्, र रिबुट शान्त देखिँदा तीमध्ये एउटा मात्र पूरा हुन्छ।