resolv.conf तुमचे VPN DNS का दाखवते पण शोध ते दुर्लक्ष करतात

लॉगमध्ये काहीही चुकीचे दिसत नाही: इंटरफेस सुरू आहे, रिझॉल्व्हर VPN च्या DNS सर्व्हरची नोंद देतो, आणि डिस्कवरील फाइल त्याची यादी करते। तरीही अंतर्गत होस्टनाव स्थानिक राउटरमार्फत सोडवले जाते। ही तीन विधाने एकमेकांविरुद्ध नाहीत, कारण फाइल, प्रत्येक लिंकची स्थिती आणि शोधाचा मार्ग या वेगवेगळ्या वस्तू आहेत ज्यांचे योगायोगाने एकच नाव आहे। पुढे systemd-resolved असलेल्या होस्टवर क्वेरी प्रत्यक्षात घेत असलेला मार्ग दिला आहे।

resolv.conf नावाच्या तीन वस्तू

resolved असलेल्या होस्टवर /etc/resolv.conf सहसा /run/systemd/resolve/stub-resolv.conf कडे जाणारी सांकेतिक लिंक असते। त्या लक्ष्यात स्थानिक stub श्रोत्याचा पत्ता, 127.0.0.53, आणि resolved ने मोजलेले शोध डोमेन असतात। हे स्थितीचे दृश्य आहे, स्थिती स्वतः नाही।

स्थिती resolved च्या प्रत्येक लिंकच्या संरचनेत राहते, म्हणूनच resolvectl status फाइलशी वेगळे मत देऊनही बरोबर असू शकते। प्रत्येक लिंक आपले सर्व्हर आणि आपले राउटिंग डोमेन घेऊन जाते, आणि क्वेरी आल्यावर stub त्या डेटाचा सल्ला घेतो। systemd-resolved चे पुस्तिका तयार होणाऱ्या फाइल्स आणि प्रत्येक लिंकचे प्रतिरूप वर्णन करते; दृश्य आणि स्थिती यांतील फरक हा लक्षात ठेवण्यासारखा भाग आहे। सांकेतिक लिंकचे लक्ष्य बदलल्याने पारंपरिक क्लायंट जे वाचतात ते बदलते, रिझॉल्व्हर जे जाणतो ते नाही।

तिसरी वस्तू, /run/systemd/resolve/resolv.conf, प्रत्येक लिंक एका सर्व्हर यादीत सपाट करते। त्या फाइलकडे निर्देशित प्रोग्राम क्वेरी थेट यादीतील सर्व्हरकडे पाठवतो आणि stub वगळतो, त्यामुळे प्रत्येक लिंकचे धोरण आता त्याला लागू होत नाही। म्हणून एकाच मशीनवरील दोन प्रोग्राम एकाच नावाला वेगळे उत्तर देऊ शकतात, आणि दोन्हीपैकी कोणतेही बिघडलेले नाही।

NSS मधून एका शोधाचा मागोवा घ्या

glibc नावाला कोण उत्तर देईल हे ठरवण्यासाठी /etc/nsswitch.conf वाचते। resolve असलेली hosts ओळ प्रश्न nss-resolve कडे पाठवते, जे D-Bus मार्फत resolved ला विचारते आणि प्रत्येक लिंकचे उत्तर मिळवते। फक्त files dns असलेली ओळ क्वेरी /etc/resolv.conf ज्याच्याकडे आहे त्या पत्त्यावर पाठवते।

ही एकच ओळ ब्राउझर आणि dig यांतील बहुतेक मतभेद स्पष्ट करते। dig थेट resolv.conf वाचते आणि NSS ला कधीही स्पर्श करत नाही, त्यामुळे ते ॲप्लिकेशन वापरत असलेल्या मार्गाऐवजी stub किंवा वरच्या सर्व्हरची चाचणी करते। getent hosts internal.example NSS मधून जाते, आणि त्याच्या उत्तराची dig च्या उत्तराशी तुलना हे पहिले उपयुक्त मापन आहे।

स्वतःचा रिझॉल्व्हर बरोबर आणणारे किंवा निश्चित एंडपॉइंटकडे HTTPS वर DNS बोलणारे ॲप्लिकेशन दोन्ही मार्ग टाळतात। resolv.conf मध्ये किंवा resolved च्या स्थितीत काहीही त्यांना मर्यादित करत नाही।

फाइल कोणाची आहे आणि कुठे निर्देश करते ते तपासा

काहीही बदलण्यापूर्वी लिंक साखळी वाचा, कारण मालकी कोणती फाइल प्रमाण आहे हे ठरवते। खालील प्रत्येक आदेश फक्त स्थिती वाचतो।

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

पहिली ओळ लिंक आणि तिचे लक्ष्य एकत्र छापते, आणि VPN स्क्रिप्टच्या मालकीची साधी फाइल म्हणजे रिझॉल्व्हर ते लिखाण कधीही इनपुट म्हणून घेत नाही। स्थितीचे आउटपुट प्रत्येक लिंकचे सर्व्हर आणि प्रत्येक क्वेरी कुठे जाते हे ठरवणारे राउटिंग डोमेन यांची यादी करते। nsswitch ओळ सांगते की stub चा सल्ला अजिबात घेतला जातो का, म्हणून फाइलमध्ये stub पत्ता असूनही तेथे resolve नसेल तर क्वेरी स्थानिक श्रोत्यापर्यंत पोहोचतात पण विभाजन कोणीही सांभाळत नाही। ती शेवटची यादीही महत्त्वाची आहे, कारण stub-resolv.conf नसलेला होस्ट येथे वर्णन केलेली रचना चालवत नाही।

साखळी दुसऱ्या पॅकेजने व्यवस्थापित केलेल्या फाइलवर संपल्यास, VPN क्लायंट आणि ते पॅकेज हे जुळवायचे दोन मालक आहेत। लिंक बदलल्याने एका मालकाचे काम टाकून दुसऱ्याचे त्याच्या जागी राहते।

लिंकच्या मालकाकडे दुरुस्त करा

VPN कनेक्शनने आपले सर्व्हर आणि डोमेन आपल्या लिंकवर नोंदवावेत, नंतर डिस्कनेक्ट होताना ते मागे घ्यावेत। NetworkManager चे resolved एकत्रीकरण आणि क्लायंटचा स्वतःचा सहायक दोन्ही असेच काम करतात; फक्त resolv.conf पुन्हा लिहिणारी स्क्रिप्ट तसे करत नाही।

आधीच अस्तित्वात असलेल्या लिंकवर रनटाइम सेटिंग्ज यंत्रणा दाखवतात। resolvectl dns tun0 10.40.0.53 एक सर्व्हर जोडते, आणि resolvectl domain tun0 '~corp.example' एक राउटिंग डोमेन जोडते। टिल्डा (~) हे भार वाहणारे अक्षर आहे: ते त्या प्रत्ययाच्या क्वेरी या लिंकपुरत्या मर्यादित करते आणि बाकी सर्व शांत ठेवते, तर त्याशिवाय तेच मूल्य शोध डोमेन होते आणि विभाजन वाफ होते। ते पत्ते प्रयोगशाळेतील उदाहरणे आहेत, कायमस्वरूपी संरचना नाहीत। resolvectl query host.corp.example ने खात्री करा आणि कोणत्या लिंकने उत्तर दिले ते वाचा।

नोंदणीकृत सर्व्हरला तरीही मार्ग लागतो। क्वेरी योग्य लिंकपर्यंत पोहोचून वेळ संपल्यास, दोष रिझॉल्व्हरच्या मालकीत नाही, तर बोगद्यातून पोहोचण्याच्या क्षमतेत आहे।

कार्यरत स्थिती कशी दिसते

निरोगी निकाल तीनही दृश्यांमध्ये सुसंगत असतो: प्रत्येक लिंकचे सर्व्हर VPN ने दिलेल्याशी जुळतात, राउटिंग डोमेन फक्त अंतर्गत प्रत्यय व्यापतात, आणि महत्त्वाचे ॲप्लिकेशन अंतर्गत नाव सोडवते तर सार्वजनिक नाव अजूनही स्थानिक मार्गाने जाते। एक यशस्वी क्वेरी त्या एकमतापेक्षा कमी सिद्ध करते।

नंतर डिस्कनेक्ट करा आणि दोन्ही क्वेरी पुन्हा करा। टियरडाउननंतर आपले डोमेन नोंदणीकृत ठेवणारा क्लायंट काही तासांनंतर अंतर्गत शोधांमध्ये अपयशी होणारे मशीन तयार करतो, उघडा बोगदा आणि स्पष्ट कारण नसताना।