Split-DNS क्याप्चर: प्रत्येक अवलोकन कहाँ लिइयो भन्नुहोस्

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

एउटा खोज, धेरै अवलोकन बिन्दु

एउटा आन्तरिक नामका लागि हेर्ने कम्तीमा पाँच ठाउँ छन्: एप्लिकेसन र त्यसले बोलाउने resolver API, क्लाइन्टमा प्रभावकारी डोमेन नीति, एडाप्टर वा फिल्टरमा क्याप्चर, नियन्त्रित गेटवे सीमा, र क्वेरी वास्तवमा प्राप्त गर्ने resolver।

प्रत्येकले फरक प्रश्नको उत्तर दिन्छ, र कुनै एउटाले मात्र क्वेरी कहाँ गयो भनी प्रमाणित गर्दैन।

एडाप्टरमा क्याप्चरले प्याकेट देखाउँछ, मनसाय होइन। यसले क्लाइन्टले कुन resolver रोज्यो भनी बताउँदैन, र खाली क्याप्चरले क्यास गरिएको उत्तर वा अर्को resolver API हुन सक्छ, फालिएको प्याकेट होइन। प्रत्येक अवलोकनलाई एउटा चरणको प्रमाण मान्नुहोस्। त्यसपछि चरणहरूलाई एउटा बाटोमा जोड्नुहोस्।

क्लाइन्टको फिल्टर एप र तारको बीचमा बस्छ

Split-DNS भएको VPN क्लाइन्टले प्याकेट मेसिन छोड्नु अघि डोमेन मिलान लागू गर्छ। टनेल गरिएको सफिक्सका नाम भित्री resolver मा जान्छन्; बाँकी सबै स्थानीय 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 उत्तरलाई त्यसपछि आउने सेवा जडानबाट अलग गर्नुहोस्: समाधान गरिएको निजी ठेगानालाई अझै मार्ग र एप अनुमति चाहिन्छ।