resolvconf डेटाबेस से पुराना VPN रिकॉर्ड हटाना

टनल बंद होने के एक दिन बाद भी एक आंतरिक नाम अब भी VPN सर्वर पर हल होता है, और रिज़ॉल्वर फ़ाइल उस प्रविष्टि के साथ बार-बार लौट आती है। जहाँ Debian का resolvconf स्थिति का स्वामी है, वहाँ वह फ़ाइल आपूर्तिकर्ता रिकॉर्ड से बनती है, और उनमें से एक बचा हुआ अवशेष है। रिकॉर्ड हटाने में एक मिनट लगता है; यह सिद्ध करना कि उसे हटाना सुरक्षित है, असली काम है। ये द्वार क्रम से चलते हैं, और कोई द्वार विफल होने पर प्रक्रिया वहीं समाप्त होती है, आपको अगले चरण पर नहीं भेजा जाता।

पुष्टि करें कि resolvconf स्थिति का स्वामी है

पहले स्वामी की पहचान करें, क्योंकि systemd-resolved के अंतर्गत वही लक्षण अलग कमांड और अलग मरम्मत माँगता है। resolvconf पैकेज /run/resolvconf के अंतर्गत एक डेटाबेस रखता है और /etc/resolv.conf को उस फ़ाइल पर इंगित करता है जो वह उसी डेटाबेस से बनाता है। दो बातें यह प्रश्न तय कर देती हैं: सिमलिंक का लक्ष्य, और यह कि पैकेज स्थापित और सक्रिय है या नहीं। /run/systemd/resolve के अंतर्गत लक्ष्य का अर्थ है दूसरा डिज़ाइन, जहाँ नीचे कुछ भी लागू नहीं होता।

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

यदि लिंक कहीं और इंगित करता है या पैकेज अनुपस्थित है, तो यहीं रुकें। किसी अन्य रिज़ॉल्वर प्रबंधक द्वारा भेजा गया, यह नाम उधार लेने वाला अनुकूलता रैपर इस डेटाबेस का स्वामी नहीं है।

डेटाबेस में इनपुट रहते हैं, उत्तर नहीं

डेटाबेस में इनपुट रहते हैं और फ़ाइल एक आउटपुट है, इसलिए इनपुट की सूची बनाना ही यह देखने का एकमात्र तरीका है कि जिस प्रविष्टि को आप हटाना चाहते हैं, उसे किस प्रोग्राम ने स्थापित किया। रिकॉर्ड छोटे होते हैं, और उनकी कुंजियाँ वही हैंडल हैं जिनकी आपको आगे आवश्यकता होगी। यह तय करने से पहले उन्हें पढ़ें कि कौन-सा पुराना है, क्योंकि VPN इंटरफ़ेस जैसा दिखने वाला नाम किसी दूसरे क्लाइंट का हो सकता है। निजी पते और आंतरिक खोज डोमेन साझा निदान से बाहर रखें; अकेली कुंजी ही सामान्यतः रिकॉर्ड की पहचान कर देती है।

sudo resolvconf --list
sudo resolvconf -i

पहला कमांड आपूर्ति किए गए रिकॉर्ड को संसाधित किए बिना छापता है, और दूसरा उन इंटरफ़ेस की सूची देता है जो इस समय DNS कॉन्फ़िगरेशन प्रदान करते हैं। कुंजियाँ पारंपरिक रूप से इंटरफ़ेस नाम और आपूर्ति करने वाले प्रोग्राम से बनती हैं। resolvconf मैनुअल उस डेटाबेस का वर्णन करता है जिसे ये कुंजियाँ संबोधित करती हैं।

कुंजी को फिर से बनाने के बजाय आउटपुट से कॉपी करें। कोई प्रविष्टि केवल इसलिए tun0 नहीं कहलाती कि किसी पुराने स्क्रिप्ट ने वह नाम इस्तेमाल किया था।

सिद्ध करें कि रिकॉर्ड का कोई स्वामी नहीं

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

प्रक्रिया नाम कमज़ोर साक्ष्य हैं। OpenConnect vpnc-script को कॉल करता है, इसलिए vpnc प्रक्रिया की जाँच यह नहीं बताती कि कौन-सा रिकॉर्ड वर्तमान है। एक नया कनेक्शन किसी पुराने कनेक्शन द्वारा छोड़े गए इंटरफ़ेस नाम का पुनः उपयोग भी कर सकता है, जिससे कुंजी अपनी वास्तविक आयु से पुरानी दिखती है। रिकॉर्ड के भीतर सर्वर पते की तुलना उन टनलों के पतों से करें जो अभी भी चालू हैं, और यदि वे मेल खाते हैं तो रुक जाएँ।

स्वामी प्रबंधक के माध्यम से सामान्य डिस्कनेक्ट पहला उपाय है। यह वह हटा देता है जो उस कनेक्शन ने स्थापित किया था और अन्य आपूर्तिकर्ताओं को अछूता छोड़ देता है।

हटाने और रीराइट की जाँच करें

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

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

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

resolvconf -u केवल वही अपडेट स्क्रिप्ट चलाता है। यह कभी भी अप्रचलित रिकॉर्ड की पहचान या उसे नहीं हटाता, और पुराने इनपुट से दोबारा बनाने पर वही अवांछित फ़ाइल फिर बन जाती है।

मारा गया डिस्कनेक्ट हुक रिकॉर्ड को पीछे छोड़ देता है

एक बार की सफ़ाई आज की स्थिति लौटा देती है, और अगला बाधित शटडाउन रिकॉर्ड को वापस ले आता है। टियरडाउन पथ पर चलें: क्लाइंट का डिस्कनेक्ट हुक, वह हेल्पर जिसे हुक कॉल करता है, और जब इनमें से कोई मारा जाता है तो क्या होता है। बाधित शटडाउन ही सामान्य कारण है, क्योंकि हुक ने बिल्कुल भी नहीं चला। हुक की एक्ज़िट स्थिति एक बार लॉग करें और आप जान जाएँगे कि वह चुपचाप विफल हो रहा है या नहीं।

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

फिर जीवनचक्र का अभ्यास करें: कनेक्ट करें, डिस्कनेक्ट करें, रिकॉर्ड फिर से सूचीबद्ध करें। प्रविष्टि का अपने आप गायब होना ही एकमात्र प्रमाण है कि मरम्मत टिकी हुई है।