तुमचा VPN तीन DNS सर्व्हर पाठवतो: कोण उत्तर देतो?
अतिरिक्त नोंदी फॉलबॅक, प्रति-डोमेन मार्ग किंवा भौतिक दुव्याचा उरलेला भाग असू शकतात। यादीला गळती म्हणण्यापूर्वी प्रत्येकाला एका व्याप्तीशी जोडा।
कनेक्ट केल्यानंतर सेटिंग्ज पृष्ठ उघडा आणि तीन DNS पत्ते सूचीबद्ध दिसतील; ऑडिटचा प्रश्न असा आहे की तुमची शेवटची क्वेरी कोणी हाताळली। फक्त संख्या कोणतेही उत्तर देत नाही, कारण क्लायंट पुश, भौतिक इंटरफेस आणि प्रति-डोमेन धोरण सर्व एकाच दृश्यात लिहितात। या नोंदींच्या वेगवेगळ्या व्याप्ती आहेत, आणि उत्तर कोण देईल हे स्थान नव्हे तर व्याप्ती ठरवते। स्रोत वेगळे करून सुरुवात करा, नंतर तुमच्यासाठी महत्त्वाचे नाव असलेला स्रोत तपासा।
यादी तुमच्या प्रोफाइलपेक्षा लांब का आहे
VPN क्लायंट टनेल दुव्यासाठी रिझोल्व्हर पत्ते पाठवतो, आणि ऑपरेटिंग सिस्टम ते भौतिक इंटरफेसकडे आधीपासून असलेल्यांच्या शेजारी ठेवते। राउटर, कॉर्पोरेट DHCP भाडेपट्टा, दुसरा VPN आणि प्रति-डोमेन धोरण प्रत्येक स्वतःची नोंद जोडते। म्हणून पृष्ठावरील तीन पत्ते एका कामासाठी तीन उमेदवार नव्हे तर तीन व्याप्ती असू शकतात। संख्येला गळतीचा पुरावा म्हणून वाचणे ही या ऑडिटमधील पहिली चूक।
एका इंटरफेसच्या आत क्लायंट खरोखर त्याचे सर्व्हर क्रमाने वापरून पाहतो, त्यामुळे क्रमबद्ध यादी अर्थहीन नाही। रांग नसलेली गोष्ट म्हणजे एकत्रित दृश्य, जिथे प्रोफाइल, भौतिक दुवा आणि प्रति-डोमेन नियमांच्या नोंदी एकाही क्रमवारीशिवाय शेजारी बसतात। हा फरक ठरवतो की तुम्ही काय तपासाल: क्रम एका व्याप्तीतील वर्तन स्पष्ट करतो, आणि व्याप्ती बाकी सर्व।
एन्क्रिप्टेड DNS चित्र ॲप्लिकेशनच्या आतून मोडते। स्वतःचा DNS-over-HTTPS रिझोल्व्हर असलेला ब्राउझर किंवा चॅट क्लायंट ऑपरेटिंग सिस्टमची यादी पूर्णपणे टाळून क्वेरी पाठवतो, त्यामुळे सेटिंग्ज पृष्ठावरील पत्ते ॲपने कधीही तयार न केलेल्या रहदारीचे वर्णन करतात। नाव चुकीचे आले म्हणून प्रोफाइलला दोष देण्यापूर्वी ॲपचे स्वतःचे रिझोल्व्हर सेटिंग तपासा।
तीन तपासण्यांपैकी प्रत्येक काय सांगते
प्रत्येक स्रोत आपली खूण वेगळ्या ठिकाणी सोडतो, आणि एकही आदेश सर्व दाखवत नाही। सेटिंग्ज पृष्ठाजवळ ठेवण्यासारखे हे मॅपिंग आहे:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
systemd-resolved वापरणाऱ्या सिस्टमवर resolvectl status अधिकृत आहे, कारण ती राउटिंग डोमेनसह प्रत्येक दुव्याचे DNS नोंदवते। macOS scutil --dns द्वारे उत्तर देते, जे व्याप्ती असलेल्या रिझोल्व्हरना वापरून पाहण्याच्या क्रमाने सूचीबद्ध करते। Windows दोन अर्धे भाग करते: प्रति-इंटरफेस सर्व्हरसाठी Get-DnsClientServerAddress आणि सफिक्स नियमांसाठी Get-DnsClientNrptPolicy। प्रत्यक्षात वापरल्या जाणाऱ्या रिझोल्व्हरशी संबंधित आदेश चालवा, कारण कंटेनर रनटाइम आणि डेस्कटॉप रिझोल्व्हर असलेल्या मशीनवर एकापेक्षा जास्त स्थापित असू शकतात।
तुमच्या झोनला उत्तर देऊ न शकणारा बॅकअप रिझोल्व्हर
दुसरी नोंद सहसा उपलब्धतेसाठी असते, आणि उपलब्धता बॅकअपला नावे माहीत असल्यासच काम करते। सार्वजनिक रिझोल्व्हरला अंतर्गत होस्टनाव विचारा, तो NXDOMAIN परत देतो, किंवा तुमच्याशी संबंध नसलेल्या शोध डोमेनमधून वाइल्डकार्ड उत्तर देतो। कोणीही न तपासलेला फेलओव्हर मग नेमक्या गरजेच्या क्षणी व्यत्यय निर्माण करतो।
Split DNS ते टाळण्यासाठी आहे: कंपनीचे सफिक्स झोन ठेवणाऱ्या रिझोल्व्हरकडे जातात, आणि सार्वजनिक नावे डीफॉल्ट मार्गावर राहतात। रचना भक्कम आहे, आणि ती सफिक्स यादी पूर्ण असण्यावर अवलंबून आहे। Microsoft प्रति-सफिक्स रिझोल्व्हर धोरणाचे दस्तऐवजीकरण करते, जे Windows वर हे चालवते, आणि तीच कल्पना systemd-resolved मध्ये राउटिंग डोमेन आणि macOS वर व्याप्ती असलेले रिझोल्व्हर म्हणून दिसते।
बॅकअप ज्या झोनना उत्तर देऊ शकतो त्यांची धोरणातील सफिक्सशी तुलना करा। ही तुलना वापरकर्त्याने टनेल बदलानंतर एक अंतर्गत साइट सोडवणे थांबले असे सांगण्यापूर्वीच अंतर शोधते।
धोरणातून विचारा, त्याभोवती नाही
ऑपरेटिंग सिस्टमच्या रिझोल्व्हरमधून विचारा, कारण सर्व्हरला थेट क्वेरी धोरण टाळते आणि तो सर्व्हर काय म्हणेल तेवढेच नोंदवते। दोन उत्तरांमधील अंतर हाच संपूर्ण मुद्दा आहे:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53सिस्टम क्वेरी खाजगी पत्ता परत देत असेल आणि थेट क्वेरी NXDOMAIN परत देत असेल, तर धोरण काम करत आहे आणि बॅकअप हा दुर्बल मुद्दा आहे। दोन्ही एकच सार्वजनिक उत्तर परत देत असल्यास, नाव तुम्ही हेतूने ठेवलेल्या व्याप्तीबाहेर सोडवले जात आहे, आणि सफिक्स यादी पाहण्याचे ठिकाण आहे। दोन्ही आउटपुट ठेवा, कारण सेटिंग्ज पृष्ठाच्या स्क्रीनशॉटपेक्षा दोन ओळींनी रिझोल्व्हर वाद लवकर मिटतो।
मग अयशस्वी मार्गाचा सराव करा, कारण कोणीही न तपासलेला फॉलबॅक एक गृहीतक आहे। एका क्वेरीसाठी पसंतीच्या रिझोल्व्हरला ब्लॅकहोल करा आणि कोणता पत्ता परत येतो ते पहा:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32क्वेरी संपताच तो मार्ग हटवा, अन्यथा पुढच्या व्यक्तीला एक कोडे वारसा म्हणून मिळते। त्या कालावधीत अंतर्गत नावे अजूनही सोडवली जात असल्यास, हेतूने ठेवलेल्या व्याप्तीबाहेरील कशाने तरी त्यांना उत्तर दिले। जर त्याऐवजी वेळ संपला, तर फॉलबॅक नाही किंवा तो योग्यरीत्या मर्यादित आहे, आणि रिझोल्व्हरचा स्वतःचा लॉग दोन्हींपैकी काय होते ते सांगतो।
ठरवा: ठेवा, मर्यादित करा किंवा काढा
दुसरा रिझोल्व्हर तेव्हा ठेवा जेव्हा तो तुम्हाला आवश्यक नामस्थानाला उत्तर देतो आणि प्रोफाइलखाली पोहोचण्यायोग्य राहतो। त्याला एका सफिक्सशी आणि दुसरे काहीही न देखण्याची गरज असेल तर मर्यादित करा, आणि त्याला व्याप्ती किंवा दस्तऐवजीकृत हेतू नसेल तर काढून टाका। काम नसलेली नोंद फायदा नसलेली भविष्यातील गळती आहे, आणि विक्रेत्याचे डीफॉल्ट हेतू नाही।
निकाल चार स्तंभांत नोंदवा: सफिक्स, रिझोल्व्हर, इंटरफेस आणि मालक। ती ओळ कोणत्याही स्क्रीनशॉटपेक्षा लवकर पुढच्या ऑडिट प्रश्नाचे उत्तर देते, आणि यादी शांतपणे पुनर्रचित करणाऱ्या क्लायंट अपडेटमधूनही टिकते।