बोगदा बंद झाल्यानंतर एक दिवस उलटूनही अंतर्गत नाव अजूनही 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 फक्त त्या अपडेट स्क्रिप्ट चालवते। ते कधीही जुनी नोंद ओळखत नाही किंवा हटवत नाही, आणि जुन्या इनपुटवरून पुन्हा बांधल्यास तीच अवांछित फाइल पुन्हा तयार होते।

ठार केलेला डिस्कनेक्ट हुक नोंद मागे सोडतो

एकदाची स्वच्छता आजची स्थिती पुनर्संचयित करते, आणि पुढील व्यत्ययित शटडाउन नोंद परत आणते। विघटनाचा मार्ग चाला: क्लायंटचा डिस्कनेक्ट हुक, तो हुक ज्याला कॉल करतो तो सहायक, आणि त्यापैकी कोणी ठार झाल्यास काय होते। व्यत्ययित शटडाउन हे नेहमीचे कारण आहे, कारण हुक अजिबात चालला नाही। हुकची निर्गमन स्थिती एकदा नोंदवा आणि तो शांतपणे अपयशी होत आहे का हे तुम्हाला कळेल।

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

मग जीवनचक्राचा सराव करा: कनेक्ट करा, डिस्कनेक्ट करा, नोंदी पुन्हा यादी करा। नोंद स्वतःहून गायब होणे हाच दुरुस्ती टिकते याचा एकमेव पुरावा आहे।

संबंधित लेख