Split-DNS कॅप्चर: प्रत्येक निरीक्षण कुठे घेतले ते सांगा

दोन लोक एकाच Split-DNS समस्येवर काम करतात आणि वेगवेगळे resolver पत्ते मिळवतात. एकाने शोध साधन वापरले, दुसऱ्याने अडॅप्टरवर पॅकेट कॅप्चर केले, आणि तिसऱ्याने क्लायंटचे स्वतःचे निदान वाचले। त्यांच्यापैकी कोणी खोटे बोलत नाही, आणि कोणी एकाच टप्प्याचे वर्णन करत नाही। निरीक्षण-बिंदूचे नाव दिल्यास विरोधाभास नकाशात बदलतो।

एक शोध, अनेक निरीक्षण-बिंदू

एका अंतर्गत नावासाठी पाहण्याची किमान पाच ठिकाणे आहेत: अनुप्रयोग आणि तो बोलावणारा resolver API, क्लायंटवरील प्रभावी डोमेन धोरण, अडॅप्टर किंवा फिल्टरवरील कॅप्चर, नियंत्रित गेटवे सीमा, आणि क्वेरी प्रत्यक्षात स्वीकारणारा resolver.

प्रत्येक वेगळ्या प्रश्नाचे उत्तर देतो, आणि एकही स्वतःहून क्वेरी कुठे गेली हे सिद्ध करत नाही।

अडॅप्टरवरील कॅप्चर पॅकेट दाखवते, हेतू नाही। ते क्लायंटने कोणता resolver निवडला हे सांगत नाही, आणि रिकामे कॅप्चर कॅश केलेले उत्तर किंवा दुसरे resolver API असू शकते, टाकून दिलेले पॅकेट नाही। प्रत्येक निरीक्षण एका टप्प्याचा पुरावा माना। नंतर टप्पे एका मार्गात जोडा।

क्लायंटचा फिल्टर अनुप्रयोग आणि तारेच्या मध्ये बसतो

Split-DNS असलेला VPN क्लायंट पॅकेट मशीन सोडण्यापूर्वी डोमेन जुळणी लागू करतो। टनल केलेल्या प्रत्ययातील नावे अंतर्गत resolver कडे जातात; बाकी सर्व स्थानिकाकडे जाते। फिल्टर धोरण आहे, आणि धोरण प्लॅटफॉर्म व क्लायंट आवृत्तीनुसार बदलू शकते।

Cisco चे Secure Client Split-DNS मार्गदर्शन डोमेन जुळणी आणि Windows फिल्टर व्यापते, आणि अनुप्रयोग स्थानिक resolver API वापरताना काय पाहतो आणि nslookup सारखे साधन काय पाहते यात फरक करते। तेच फरक मुख्य मुद्दा आहेत.

प्रभावी प्रोफाइल आणि एका सामान्य अनुप्रयोग शोधापासून सुरुवात करा। विशिष्ट सर्व्हरचे नाव देणारी कोणतीही चाचणी जाणीवपूर्वक केलेला वळसा आहे; ती क्लायंटच्या स्वतःच्या निदानाने समजावून सांगा, आणि ती स्वीकृती-निकष होऊ देऊ नका।

nslookup अनुप्रयोगापेक्षा वेगळा मार्ग घेतो

nslookup स्वतःची DNS क्वेरी तयार करतो आणि ऑपरेटिंग सिस्टमचे resolver धोरण टाळू शकतो। त्यामुळे विशिष्ट सर्व्हरला विशिष्ट प्रश्न विचारण्यासाठी तो उपयुक्त साधन ठरतो, आणि अनुप्रयोग काय अनुभवेल हे तपासण्यासाठी दिशाभूल करणारे साधन ठरतो।

Windows मध्ये नाव-निराकरण धोरण सारणी कोणता प्रत्यय कोणता सर्व्हर वापरतो हे ठरवते। ती वाचल्यास अनुप्रयोग कोणते धोरण पाळेल ते दिसते, आणि बऱ्याचदा तोच गहाळ तुकडा असतो।

धोरण वाचा आणि नंतर तोच प्रश्न सामान्य resolver मार्गे विचारा:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

एन्क्रिप्टेड resolver क्वेरी लपवतात, कनेक्शन नाही

स्वतःचा DNS-over-HTTPS resolver असलेला ब्राउझर पूर्णपणे वेगळी परिस्थिती आहे। क्वेरी TLS मध्ये बाहेर पडते, त्यामुळे पॅकेट कॅप्चर resolver पत्त्याशी कनेक्शन दाखवते पण विचारलेले नाव दाखवत नाही।

प्रथम ब्राउझरचे व्यवस्थापित धोरण शोधा, नंतर ते ऑपरेटिंग सिस्टमच्या शोधाशी तुलना करा। स्वतःचा resolver निवडण्याची परवानगी असलेला ब्राउझर Split-DNS धोरण कधीच पाहू शकत नाही।

तीच सावधानी स्वतःचा resolver आणणाऱ्या प्रत्येक क्लायंटला लागू होते। दूरचे कनेक्शन ओळखणारे कॅप्चर क्वेरीच्या नावाचा पुरावा नाही। नाव आवश्यक असल्यास, ते resolver च्या स्वतःच्या लॉगमधून किंवा अनुप्रयोगाच्या निदानातून घ्या, लागू असलेल्या गोपनीयता नियमांसह.

लेबल केलेल्या चाचणीशी तुलना करा

चाचणीसाठी मंजूर अंतर्गत नाव, तसेच संवेदनशील अर्थ नसलेले सार्वजनिक नाव निवडा। प्रत्येकासाठी वेळ, रेकॉर्ड प्रकार, उत्तर आणि अपेक्षित धोरण नोंदवा।

जिथे मंजूर असेल, resolver ची प्राप्ती एका अरुंद क्लायंट किंवा गेटवे निरीक्षणाशी तुलना करा:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

फक्त तुलना तयार करण्यासाठी खाजगी नावे असंबंधित सार्वजनिक resolver कडे कधीही पाठवू नका, आणि तुम्ही सामायिक करता ते सर्व संपादित करा। शेवटी, योग्य DNS उत्तर त्यानंतर येणाऱ्या सेवा-कनेक्शनपासून वेगळे करा: सोडवलेल्या खाजगी पत्त्याला अजूनही मार्ग आणि अनुप्रयोग परवानगी आवश्यक आहे।