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/ वाचा, जे मागे सेवा नसताना टनेल परत येण्याचे स्पष्टीकरण देते। अजूनही काही बाहेर डायल करत असेल, तर लक्षण थांबेपर्यंत फाइल्स हटवण्याऐवजी प्रक्रियेचा पालकापर्यंत मागोवा घ्या। मशीन साफ करणे आणि खाते रद्द करणे वेगवेगळी कामे राहतात, आणि रीबूट शांत दिसताना त्यापैकी एकच पूर्ण होते।