resolvectl आउटपुट से हर लिंक के लिए VPN DNS राउटिंग कैसे पढ़ें
resolvectl status हर लिंक के लिए सर्वर, डोमेन और डिफ़ॉल्ट रूट दिखाता है। इन्हें साथ पढ़ें, फिर नाम पूछें और देखें कि किस लिंक ने उत्तर दिया।
resolvectl status चलाएँ और आपको हर लिंक के लिए ब्लॉकों की दीवार मिलेगी, हर एक के अपने सर्वर और अपनी डोमेन पंक्ति। राउटिंग तय करने वाली पंक्ति डोमेन सूची है, नेमसर्वर का पता नहीं, क्योंकि स्थानीय स्टब हर प्रश्न उस लिंक को भेजता है जो नाम का दावा करता है। उत्तर पढ़ने से पहले वे दावे पढ़ें, फिर नाम पूछें और जाँचें कि किस लिंक ने उसे बनाया। सही लिंक से गलत उत्तर, गलत लिंक से सही उत्तर से अलग समस्या है।
हर लिंक-ब्लॉक आपको क्या बताता है
हर ब्लॉक उन सर्वरों को सूचीबद्ध करता है जिन्हें रिज़ॉल्वर उस इंटरफ़ेस के लिए उपयोग करेगा, डोमेन सूची और यह कि लिंक डिफ़ॉल्ट रूट है या नहीं। डोमेन सूची दावों का समूह है और रिज़ॉल्वर सबसे लंबे प्रत्यय का मिलान लगाता है: host.corp.example के लिए प्रश्न पर corp.example वाला लिंक पहले दावा करता है, केवल डिफ़ॉल्ट रूट वाले लिंक से पहले। एक ही प्रत्यय पर दावा करने वाले दो लिंक परिणाम को प्राथमिकता और क्रम पर छोड़ देते हैं, इसलिए नकलें पहले ध्यान देने योग्य हैं। वर्तमान सर्वर पंक्ति दिखाती है कि सूचीबद्ध सर्वरों में से कौन उस क्षण उपयोग में है।
/etc/resolv.conf में 127.0.0.53 जैसा स्टब पता केवल यह कहता है कि स्टब आगे है। यह उस अपस्ट्रीम का नाम नहीं बताता जिसने उत्तर दिया, इसलिए केवल resolv.conf पर आधारित निदान अटक जाता है।
तीनों प्रकार की डोमेन प्रविष्टियाँ ठीक से पढ़ें
| प्रविष्टि | किस पर दावा | आम गलती |
|---|---|---|
| corp.example | राउटिंग डोमेन और खोज प्रत्यय: इसके नीचे के नाम इस लिंक पर जाते हैं, और स्ट्रिंग नंगे नामों में जोड़ी जाती है | हटा दिया क्योंकि राउटिंग वैसे भी काम करती दिखती है |
| ~corp.example | केवल रूट: इसके नीचे के नाम इस लिंक पर जाते हैं, पर प्रत्यय नहीं जोड़ा जाता | मान लिया कि राउटिंग के लिए यह आवश्यक है |
| ~. | डिफ़ॉल्ट रूट: उन प्रश्नों पर दावा करता है जिन्हें कोई अन्य लिंक नहीं ढकता | विभाजित प्रोफ़ाइल पर सक्रिय छोड़ा गया, इसलिए सार्वजनिक नाम टनल का पालन करते हैं |
टिल्डा खोज का व्यवहार बदलता है, राउटिंग नहीं। बिना टिल्डा वाली प्रविष्टि राउटिंग डोमेन और खोज डोमेन दोनों है, इसलिए इसके नीचे के नाम उस लिंक पर भेजे जाते हैं और एक-लेबल नामों में प्रत्यय जोड़ा जाता है। टिल्डा प्रविष्टि वही प्रत्यय राउट करती है पर उसे खोज सूची से बाहर रखती है। इसलिए टिल्डा हटाने से बदलता है कि कौन से नंगे नाम हल होते हैं, और इसलिए टिल्डा का न होना खोज की समस्या है, विभाजित DNS की विफलता नहीं।
डिफ़ॉल्ट रूट प्रविष्टि उस सब पर दावा करती है जिसे कोई अन्य लिंक नहीं ढकता। पूर्ण-टनल प्रोफ़ाइल सामान्यतः इसे चाहती है और विभाजित प्रोफ़ाइल सामान्यतः नहीं, क्योंकि तब सार्वजनिक नाम निजी रिज़ॉल्वर तक जाते हैं और वहाँ विफल हो सकते हैं। प्रोफ़ाइलों के बीच फ़्लैग कॉपी करने के बजाय प्रोफ़ाइल के इरादे के सामने तालिका पढ़ें। जब दो लिंक एक ही प्रत्यय पर दावा करें, तो कुछ और संपादित करने से पहले प्राथमिकता का प्रश्न तय करें।
नाम पूछें और देखें किस लिंक ने उत्तर दिया
query उप-आदेश पता, प्रोटोकॉल और वह लिंक या दायरा छापता है जिसने उत्तर बनाया। एक नाम जाँचें जिस पर निजी प्रत्यय का दावा होना चाहिए और एक सामान्य सार्वजनिक नाम, फिर बताए गए स्रोतों की तुलना करें। यदि निजी नाम वायरलेस लिंक से उत्तर दे, तो दावा गायब है या टनल बंद है; यदि विभाजित प्रोफ़ाइल में सार्वजनिक नाम टनल से उत्तर दे, तो डिफ़ॉल्ट रूट बहुत चौड़ा है। ये दोनों विफलताएँ ब्राउज़र में एक जैसी और इस आउटपुट में उलटी दिखती हैं।
resolvectl status
resolvectl query host.corp.example
बताए गए प्रोटोकॉल पर भी ध्यान दें, क्योंकि कैश या होस्ट-फ़ाइल से उत्तर किसी भी अपस्ट्रीम से पूछे बिना आ सकता है। कैश से उत्तर सिद्ध करता है कि नाम कभी हल हुआ था, यह नहीं कि वर्तमान नीति उसे ठीक से राउट करती है।
नाम राउटिंग को पैकेट राउटिंग से अलग रखें
रिज़ॉल्वर का निर्णय मार्ग नहीं बनाता। चुने गए सर्वर को अब भी अपने पते तक रूट चाहिए, और लौटाए गए पते को अब भी निजी नेटवर्क में रूट चाहिए, इसलिए सही DNS नीति ऐसे कनेक्शन के साथ रह सकती है जो कभी नहीं खुलता। जब नाम हल हो और एप्लिकेशन विफल हो, तो फिर से DNS बदलने के बजाय पता और रूट जाँचें। नाम हल होना और पहुँच दो अलग मालिकों वाले दो प्रश्न हैं।
एप्लिकेशन अपनी सुरक्षित DNS सेटिंग या बंडल किए गए रिज़ॉल्वर के ज़रिए सिस्टम रिज़ॉल्वर को पूरी तरह बायपास कर सकते हैं। resolvectl परिणाम सिस्टम मार्ग बताता है, और उसे अनदेखा करने वाला ब्राउज़र आपके हर परीक्षण से असहमत होगा। नीति टूटी है ऐसा निष्कर्ष निकालने से पहले वह सेटिंग जाँचें।
जिस पते पर नाम हल हुआ उसे लिंक के साथ दर्ज करें। गलत पते की ओर इशारा करता सही नाम राउटिंग नहीं, रिकॉर्ड की समस्या है।
लिंक बदलने के बाद फिर जाँचें
फिर से कनेक्ट होना या वायरलेस बदलना लिंक की स्थिति फिर से बनाता है, और नेटवर्क मैनेजर हाथ से सेट की गई हर चीज़ के ऊपर अपने डोमेन और सर्वर फिर से स्थापित कर सकता है। फिर वही दो नाम पूछें और दर्ज आधार-रेखा से तुलना करें। यदि हाथ का संपादन गायब हो गया हो, सुधार कनेक्शन प्रोफ़ाइल में होना चाहिए शेल आदेश में नहीं। पहले और बाद में दर्ज करना ही इसे दृश्य बनाता है।
रिपोर्ट को जिन नामों और सर्वर संदर्भ की ज़रूरत है केवल वही साझा करें, क्योंकि आंतरिक प्रत्यय टोपोलॉजी उजागर करते हैं। systemd-resolved का डोमेन राउटिंग दस्तावेज़ सबसे लंबे मिलान का नियम और टिल्डा का व्यवहार समेटता है, और एक बार पढ़ना ऊपर की तालिका की अधिकांश गलतियाँ रोक देता है: systemd-resolved में प्रश्न राउटिंग।