resolvectl आउटपुटबाट प्रत्येक लिङ्कको VPN DNS राउटिङ कसरी पढ्ने

resolvectl status चलाउँदा प्रत्येक लिङ्कका लागि ब्लकको भित्ता आउँछ, प्रत्येकका आफ्नै सर्भर र आफ्नै डोमेन लाइन हुन्छ। राउटिङ तय गर्ने लाइन डोमेन सूची हो, नेमसर्भरको ठेगाना होइन, किनकि स्थानीय स्टबले प्रत्येक प्रश्न नाम दाबी गर्ने लिङ्कमा पठाउँछ। जवाफ पढ्नुअघि ती दाबीहरू पढ्नुहोस्, त्यसपछि नाम सोध्नुहोस् र कुन लिङ्कले त्यो बनायो जाँच्नुहोस्। सही लिङ्कबाट गलत जवाफ गलत लिङ्कबाट सही जवाफभन्दा फरक समस्या हो।

प्रत्येक लिङ्क ब्लकले तपाईंलाई के भन्छ

प्रत्येक ब्लकले रिजोल्भरले त्यो इन्टरफेसका लागि प्रयोग गर्ने सर्भरहरू, डोमेन सूची र लिङ्क डिफल्ट रुट हो कि होइन सूचीबद्ध गर्छ। डोमेन सूची दाबीहरूको समूह हो, र रिजोल्भरले सबैभन्दा लामो प्रत्ययको मिलान लगाउँछ: host.corp.example का लागि प्रश्न corp.example भएको लिङ्कले, केवल डिफल्ट रुट भएको लिङ्कभन्दा पहिले दाबी गर्छ। एउटै प्रत्यय दाबी गर्ने दुई लिङ्कले नतिजा प्राथमिकता र क्रममा छोड्छन्, त्यसैले प्रतिलिपिहरू पहिले ध्यान दिन योग्य छन्। हालको सर्भर लाइनले सूचीमा भएको कुन सर्भर त्यो क्षण प्रयोगमा छ देखाउँछ।

/etc/resolv.conf मा 127.0.0.53 जस्तो स्टब ठेगानाले स्टब अगाडि छ भन्ने मात्र बताउँछ। यसले जवाफ दिने माथिल्लो स्रोतको नाम लिँदैन, त्यसैले केवल resolv.conf मा आधारित निदान अड्किन्छ।

तीन प्रकारका डोमेन प्रविष्टि ठीकसँग पढ्नुहोस्

टिल्डाले खोज व्यवहार बदल्छ, राउटिङ होइन। टिल्डा नभएको प्रविष्टि राउटिङ डोमेन र खोज डोमेन दुवै हो, त्यसैले यसको तलका नाम त्यो लिङ्कमा पठाइन्छ र एक-लेबल नाममा प्रत्यय थपिन्छ। टिल्डा प्रविष्टिले त्यही प्रत्यय राउट गर्छ तर खोज सूचीबाट बाहिर राख्छ। त्यसैले टिल्डा हटाउँदा कुन नाङ्गो नाम समाधान हुन्छन् त्यो बदलिन्छ, र त्यसैले टिल्डा नहुनु खोजको समस्या हो, विभाजित DNS को विफलता होइन।

डिफल्ट रुट प्रविष्टिले अरू कुनै लिङ्कसँग नमिल्ने सबै दाबी गर्छ। पूर्ण-टनेल प्रोफाइलले सामान्यतया त्यो चाहन्छ र विभाजित प्रोफाइलले सामान्यतया चाहँदैन, किनकि त्यसपछि सार्वजनिक नामहरू निजी रिजोल्भरतिर जान्छन् र त्यहाँ विफल हुन सक्छन्। प्रोफाइलहरूबीच झन्डा प्रतिलिपि गर्नुको सट्टा प्रोफाइलको उद्देश्यसँग तुलना गरेर तालिका पढ्नुहोस्। जब दुई लिङ्कले एउटै प्रत्यय दाबी गर्छन्, अरू केही सम्पादन गर्नुअघि प्राथमिकताको प्रश्न टुंग्याउनुहोस्।

नाम सोध्नुहोस् र कुन लिङ्कले जवाफ दियो हेर्नुहोस्

query उप-आदेशले ठेगाना, प्रोटकल र जवाफ बनाउने लिङ्क वा दायरा छाप्छ। निजी प्रत्ययले दाबी गर्नुपर्ने एउटा नाम र एउटा सामान्य सार्वजनिक नाम परीक्षण गर्नुहोस्, त्यसपछि रिपोर्ट गरिएका स्रोतहरू तुलना गर्नुहोस्। निजी नामले वायरलेस लिङ्कबाट जवाफ दिन्छ भने दाबी छैन वा टनेल बन्द छ; विभाजित प्रोफाइलमा सार्वजनिक नामले टनेलबाट जवाफ दिन्छ भने डिफल्ट रुट धेरै फराकिलो छ। ती दुई विफलता ब्राउजरमा एउटै र यो आउटपुटमा उल्टो देखिन्छन्।

resolvectl status
resolvectl query host.corp.example

रिपोर्ट गरिएको प्रोटकलमा पनि ध्यान दिनुहोस्, किनकि क्यास वा होस्ट फाइलबाट जवाफ कुनै पनि माथिल्लो स्रोत नसोधी आउन सक्छ। क्यासबाट आएको जवाफले नाम कुनै बेला समाधान भएको प्रमाण दिन्छ, हालको नीतिले त्यसलाई ठीकसँग राउट गर्छ भन्ने होइन।

नाम राउटिङलाई प्याकेट राउटिङबाट अलग राख्नुहोस्

रिजोल्भरको निर्णयले मार्ग बनाउँदैन। छानिएको सर्भरलाई अझै आफ्नो ठेगानासम्म रुट चाहिन्छ, र फर्किएको ठेगानालाई अझै निजी नेटवर्कमा रुट चाहिन्छ, त्यसैले सही DNS नीति कहिल्यै नखुल्ने जडानसँगै रहन सक्छ। नाम समाधान भयो तर एप्लिकेसन विफल भयो भने, फेरि DNS बदल्नुको सट्टा ठेगाना र मार्ग जाँच्नुहोस्। नाम समाधान र पहुँच दुई फरक मालिकका दुई प्रश्न हुन्।

एप्लिकेसनहरूले आफ्नै सुरक्षित DNS सेटिङ वा बन्डल गरिएको रिजोल्भरमार्फत प्रणाली रिजोल्भरलाई पूर्ण रूपमा बाइपास गर्न सक्छन्। resolvectl नतिजाले प्रणाली मार्ग वर्णन गर्छ, र त्यसलाई बेवास्ता गर्ने ब्राउजर तपाईंले गर्ने प्रत्येक परीक्षणसँग असहमत हुनेछ। नीति बिग्रिएको छ भन्ने निष्कर्ष निकाल्नुअघि त्यो सेटिङ जाँच्नुहोस्।

नाम समाधान भएको ठेगाना लिङ्कको छेउमा नोट गर्नुहोस्। गलत ठेगानातिर देखाउने सही नाम राउटिङ होइन, रेकर्डको समस्या हो।

लिङ्क बदलिएपछि फेरि जाँच्नुहोस्

फेरि जडान वा वायरलेस परिवर्तनले लिङ्कको अवस्था फेरि बनाउँछ, र नेटवर्क म्यानेजरले हातले सेट गरेको सबैमाथि आफ्ना डोमेन र सर्भर फेरि स्थापना गर्न सक्छ। त्यसपछि तीही दुई नाम सोध्नुहोस् र नोट गरिएको आधाररेखासँग तुलना गर्नुहोस्। हातको सम्पादन हराएको छ भने, सुधार जडान प्रोफाइलमा हुनुपर्छ शेल आदेशमा होइन। अघि र पछि नोट गर्नु नै यसलाई देखिने बनाउँछ।

रिपोर्टलाई चाहिने नाम र सर्भर सन्दर्भ मात्र साझा गर्नुहोस्, किनकि आन्तरिक प्रत्ययले टोपोलोजी खोल्छन्। systemd-resolved को डोमेन राउटिङ कागजातले सबैभन्दा लामो मिलानको नियम र टिल्डाको व्यवहार समेट्छ, र एकपटक पढ्दा माथिको तालिकाका धेरै गल्ती रोकिन्छन्: systemd-resolved मा प्रश्न राउटिङ।