के VPN ले मेरो DNS परिवर्तन गर्यो? अघि र पछि तुलना गर्नुहोस्
प्रोफाइलले तपाईंका क्वेरीहरू जानाजान सार्न सक्छ। VPN जोडिनु अघि र पछि रिजोल्भर नीति र वास्तविक उत्तर तुलना गर्नुहोस्, एउटा चल स्थिर राखेर।
तपाईं टनेल जोड्नुहुन्छ, निजी ड्यासबोर्ड खोल्नुहुन्छ, र नाम तपाईंले कहिल्यै नदेखेको ठेगानामा समाधान हुन्छ। वा उल्टो हुन्छ: ब्राउजर काम गरिरहन्छ, तर कमाण्ड-लाइन उपकरण अचानक केही पनि समाधान गर्दैन। दुवै परिणाम एउटै परिवर्तनबाट आउँछन्, र मानिसहरूले सामान्यतया यसलाई VPN "आफ्नै DNS प्रयोग गर्छ" भन्ने एउटा वाक्यले व्याख्या गर्छन्, जुन डिबग गर्न वा प्रमाणित गर्न पर्याप्त सटीक छैन। त्यो वाक्यमा दुई प्रश्न लुकेका छन्: यो प्रोफाइलले कुन क्वेरीहरू लिनुपर्छ, र तपाईंको मेसिनले तिनीहरूलाई साँच्चै आफूलाई दिइएको रिजोल्भरकहाँ पठायो? तिनीहरूलाई अलग राख्नु नै सम्पूर्ण विधि हो, किनकि तिनीहरूलाई मिसाउने परीक्षणले दुवै दिशामा आत्मविश्वासी गलत उत्तर दिन्छ।
प्रोफाइलले किन रिजोल्भर दिन्छ
टनेलभित्र, टाढाको छेउपछाडिका नामहरू सामान्यतया त्यो सञ्जालमा मात्र हुने ठेगानामा समाधान हुन्छन्। corp.internal जस्तो निजी क्षेत्रसँग सार्वजनिक प्रतिनिधित्व छैन, त्यसैले त्यसलाई उत्तर दिने रिजोल्भर टनेलभित्रबाट पुग्न सकिने हुनुपर्छ। त्यही संयन्त्रले दोस्रो उद्देश्य पनि पूरा गर्छ: जब क्वेरीहरू अन्यथा तपाईंको ISP मार्फत बाहिर जान्थे, टाढाको छेउको रिजोल्भरले क्वेरीलाई इन्क्रिप्टेड बाटोभित्र राख्छ। त्यसैले DNS सर्भरको ठेगाना जडानको नीतिको भागका रूपमा आउँछ, मेसिनका लागि एकपटक छानिएको विश्वव्यापी सेटिङका रूपमा होइन।
ठेगाना आफैले केही निर्णय गर्दैन। रिजोल्भरले त्यसतर्फ बाटो भएमा मात्र उत्तर दिन सक्छ, र सबैभन्दा सामान्य खराबी भनेको टनेल उठेको बेलामा मात्र पुग्न सकिने रिजोल्भर हो। टनेल खस्दा र नीति रहँदा, क्वेरीहरू बाटो नभएको ठेगानामा जान्छन्, र लक्षण सफा त्रुटि होइन, समय सकिनु हो। अर्को परीक्षण परिणाम पढ्दा यो भिन्नता महत्त्वपूर्ण छ, किनकि समय सकिँदा मानिसहरूलाई कहिल्यै संलग्न नभएका यातायात सेटिङतर्फ पठाउँछ।
उत्तरहरू तुलना गर्नु अघि दुई डिजाइन तुलना गर्नुहोस्
पूर्ण टनेल र विभाजित DNS विपरीत अपेक्षा उत्पन्न गर्छन्, र दुवैमध्ये कुनै पनि खराबी होइन। पूर्ण टनेलअन्तर्गत हरेक क्वेरी प्रदायक वा कर्पोरेट रिजोल्भरकहाँ जान सक्छ, त्यसैले जोडिएपछि सार्वजनिक नामहरू फरक उत्तर दिनु अपेक्षित हो। विभाजित DNS अन्तर्गत सूचीबद्ध डोमेनहरू मात्र निजी रिजोल्भरकहाँ जान्छन्, बाँकी सबै स्थानीय रहन्छ; Windows मा डोमेन सूची Name Resolution Policy Table मा, macOS मा DNS सेटिङका मिल्ने डोमेनहरूमा, र systemd-resolved होस्टमा प्रत्येक लिङ्कको राउटिङ डोमेनहरूमा हुन्छ।
यही पहिले गर्नुपर्ने तुलना हो, किनकि कसलाई खराबी मान्ने भन्ने यसैले निर्धारण गर्छ। विभाजित DNS मा, नयाँ रिजोल्भरबाट उत्तर दिने सार्वजनिक नाम नै अनुसन्धान गर्न योग्य हुन्छ, जबकि सही रूपमा उत्तर दिने आन्तरिक नाम भनेको प्रणाली आफ्नो काम गरिरहेको हो। पूर्ण टनेलमा, अझै तपाईंको ISP रिजोल्भरबाट उत्तर दिने सार्वजनिक नाम नै असामान्यता हो। Microsoft को VPN नाम समाधानसम्बन्धी कागजात ले यी नियमहरूको Windows क्रम वर्णन गर्छ, मिल्ने नीति प्रविष्टि एडाप्टरका आफ्नै सर्भरभन्दा अघि कसरी विचार गरिन्छ भन्ने पनि।
कोठामा बिर्सन सजिलो तेस्रो रिजोल्भर पनि छ। ब्राउजरको सुरक्षित DNS ले आफै नामहरू समाधान गर्छ र टनेलले अपरेटिङ सिस्टमको नीति बदलेपछि पनि उत्तर दिइरहन सक्छ, त्यसैले लोड हुने पृष्ठले ब्राउजरको रिजोल्भर चलेको प्रमाण दिन्छ, प्रोफाइल लागू भएको होइन। यदि तपाईं ब्राउजरले देखाउने कुराको मात्र तुलना गर्नुहुन्छ भने, आधा समय गलत तह परीक्षण गरिरहनुभएको हुन्छ।
एउटा मात्र चलसँग आधाररेखा अभिलेख गर्नुहोस्
टनेल बदल्नुहोस्। उही चरणमा नाम, उपकरण वा खोज प्रत्यय पनि नबदल्नुहोस्। सोध्न अनुमति भएको नाम छान्नुहोस्, कुन अनुप्रयोग प्रयोग गर्नुभयो टिप्नुहोस्, र फर्केको ठेगाना वा ठ्याक्कै त्रुटि लेख्नुहोस्। Windows मा Get-DnsClientServerAddress -AddressFamily IPv4 ले प्रत्येक एडाप्टरका सर्भर छाप्छ र Get-DnsClientNrptPolicy ले नीति प्रविष्टिहरू छाप्छ; systemd-resolved सहितको Linux मा resolvectl status ले प्रत्येक लिङ्कका DNS सर्भर र राउटिङ डोमेन देखाउँछ; macOS मा scutil --dns ले प्रणालीले साँच्चै पछ्याउने रिजोल्भर क्रम छाप्छ।
त्यसपछि क्लाइन्टका सामान्य नियन्त्रणहरूबाट जोडिनुहोस् र ठ्याक्कै उही आदेशहरू दोहोर्याउनुहोस्। पहिलो आउटपुट सम्झनुको सट्टा सुरक्षित राख्नुहोस्, किनकि तुलना नै सम्पूर्ण कुरा हो र क्यास खाली गरेपछि लिइएको दोस्रो पढाइ पहिले नै अर्को मापन हो। यदि आधाररेखा ब्राउजर अगाडि राखेर लिइएको थियो र जोडिएपछिको काम टर्मिनलमा हुन्छ भने, तपाईं दुई रिजोल्भरको तुलना गर्दै हुनुहुन्छ, एउटै रिजोल्भरका दुई अवस्थाको होइन।
स्पष्ट क्वेरी र अनुप्रयोग खोज फरक परीक्षण हुन्
एउटा निश्चित सर्भरलाई सोध्नु, nslookup name 10.20.0.1 वा dig @10.20.0.1 name प्रयोग गरेर, एउटै कुरा प्रमाणित गर्छ: तपाईंले नाम दिएको सर्भर त्यहाँसम्म पुग्न सक्दा उत्तर दिन्छ। यसले छनोट तर्कलाई पूर्ण रूपमा बाइपास गर्छ, त्यसैले प्रणालीले यो नामका लागि त्यो सर्भर छान्थ्यो कि भन्न सक्दैन। तोकिएको रिजोल्भर पुग्न सकिने छ कि छैन परीक्षण गर्न यो प्रयोग गर्नुहोस्, र नीति परीक्षण गर्न यो प्रयोग नगर्नुहोस्।
स्थानीय रिजोल्भरमार्फत गरिएको खोजले छनोटलाई साँच्चै प्रयोग गर्छ। resolvectl query name ले त्यही राउटिङ-डोमेन नियमहरू पार गर्छ र कुन प्रोटोकलले उत्तर दियो जनाउँछ, Windows मा Resolve-DnsName नीति तालिका र क्लाइन्ट क्यासबाट जान्छ, र scutil --dns ले खोजले पछ्याउने क्रम देखाउँछ। दुवै प्रकार चलाउनुहोस् र तिनीहरूलाई तपाईंका टिप्पणीका छुट्टै स्तम्भमा राख्नुहोस्। सफल स्पष्ट क्वेरीको छेउमा असफल अनुप्रयोग खोज भएको छ भने त्यो राउटिङ वा छनोटको समस्या हो, काम गर्न इन्कार गर्ने रिजोल्भर होइन।
क्यास तपाईं र उत्तरबीच उभिन्छ। अपरेटिङ सिस्टम, स्थानीय स्टब रिजोल्भर, ब्राउजर र ऋणात्मक क्यास सबैले नतिजा राख्छन्, त्यसैले एउटै प्याकेट मेसिन नछोडी खोज सफल हुन सक्छ। केही खाली गर्नु अघि नतिजा अभिलेख गर्नुहोस्: ipconfig /flushdns, resolvectl flush-caches वा macOS मा sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder। यो चरणमा व्यापक सञ्जाल रिसेट छोड्नुहोस्, किनकि यसले तपाईंले अझै संकलन गरिरहनुभएको प्रमाण नष्ट गर्छ।
यो भिन्नताको अर्थ के हो
तपाईंले अभिलेख गरेका दुई पङ्क्ति तुलना गर्नुहोस् र एउटै सेटिङ छुनु अघि परिवर्तन वर्गीकरण गर्नुहोस्।
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
एउटा पङ्क्ति विशेष जोड दिन योग्य छ। समाधान हुने नाम काम गर्ने सेवा होइन, र DNS को सफलताले ठेगाना भेटियो भन्ने मात्र बताउँछ। यसले फर्वार्डिङ, फायरवाल नियम वा तपाईंको खाताले यो सेवा प्रयोग गर्न पाउँछ कि भन्नेबारे केही बताउँदैन, त्यसैले खराबी आफै हट्यो भनेर अनुमान गर्नुको सट्टा वास्तविक अनुप्रयोग परीक्षण गरेर अन्त्य गर्नुहोस्।
आधाररेखा पुनर्स्थापित गरी प्रमाणित गर्नुहोस्
प्रक्रिया मार्नुको सट्टा क्लाइन्टका आफ्नै नियन्त्रणहरूबाट डिस्कनेक्ट गर्नुहोस्, त्यसपछि उही तीन आदेश फेरि पढ्नुहोस्। प्रत्येक लिङ्कका सर्भर, नीति प्रविष्टि र तपाईंको परीक्षण नामको उत्तर पहिले लेखिएको आधाररेखामा फर्कनुपर्छ। सफा डिस्कनेक्टपछि बाँकी रहेको नीति प्रविष्टि अभिलेख गर्न योग्य वास्तविक दोष हो, र त्यसैले उत्पन्न गरिएको रिजोल्भर फाइलमा हातले सम्पादन गर्नु खराब बानी हो: फाइल फेरि लेखिन्छ र सम्पादन हराउँछ, वा सम्पादन टिक्छ र अब बाटो नभएको रिजोल्भरलाई पिन गर्छ।
यो सूची एकपटक, क्रममा गर्नुहोस्। कुनै पनि नतिजा निर्णय गर्नु अघि प्रोफाइलले कुन डिजाइन लागू गर्छ निर्धारण गर्नुहोस्। दुवै पटक नाम, उपकरण र प्रत्यय स्थिर राख्नुहोस्। स्पष्ट क्वेरीलाई अनुप्रयोग खोजबाट अलग गर्नुहोस्। उत्तर मात्र होइन, प्रभावकारी नीति पढ्नुहोस्। तुलना लेखिएपछि क्यासहरू अन्तमा खाली गर्नुहोस्। वास्तविक अनुप्रयोगसँग प्रमाणित गर्नुहोस्, त्यसपछि एकपटक रिबुट गरी डिस्कनेक्ट अवस्था अझै सफा छ भनी पुष्टि गर्नुहोस्।