VPN जोडिएको छ तर नामहरू असफल हुन्छन्: DNS साँच्चै कहाँ टुट्छ

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

खोजलाई साँच्चै के चाहिन्छ

खोजलाई तीन चीज चाहिन्छ: रिजोल्भरको ठेगाना, त्यो ठेगानासम्मको मार्ग र प्रश्नसँग मिल्ने उत्तर। हरेक अलग-अलग असफल हुन सक्छ, र देखिने लक्षण नलोड हुने त्यही पृष्ठ हो। त्यसैले तीनमध्ये कुन टुट्यो भन्ने थाहा नभएसम्म त्रुटि पृष्ठले तपाईंलाई लगभग केही भन्दैन।

ग्राहकले आफ्नो रिजोल्भर VPN प्रोफाइलबाट, सुरुङको DHCPबाट वा आफ्नै कन्फिगरेसनबाट सिक्छ, र कुन स्रोत जित्छ भन्ने प्लेटफर्ममा निर्भर हुन्छ। Windows मा, ipconfig /all हरेक एडाप्टरका लागि DNS सर्भर देखाउँछ, त्यसैले पठाइएको मान साँच्चै पुग्यो कि भनेर तपाईं देख्न सक्नुहुन्छ। अपरेटिङ सिस्टमसम्म कहिल्यै नपुगेको पठाइएको मान शान्त र सामान्य असफलता हो। प्रोफाइल छुनुअघि कन्फिगर गरिएको मान पढ्नुहोस्।

Linux र macOS एउटै प्रश्नको उत्तर फरक आदेशले दिन्छन्, र उत्तर पनि त्यही पढाइको योग्य छ: resolvectl status र scutil --dns दुवैले हरेक इन्टरफेसका लागि सर्भर सूचीबद्ध गर्छन्। त्यो सूचीलाई प्रोफाइलले पठाउने दाबी गरेको ठेगानासँग तुलना गर्नुहोस्। यहाँको अमिल्दोले तलको सबै कुरा व्याख्या गर्छ, त्यसैले नाम परीक्षण गर्नुअघि यसलाई टुंग्याउनुहोस्।

एउटा सार्वजनिक र एउटा निजी नाम परीक्षण गर्नुहोस्

एउटै मेसिनबाट सामान्य सार्वजनिक होस्टनाम र अभिलेखित निजी होस्टनाम सोध्नुहोस् र कुन सर्भरले कसलाई उत्तर दियो लेख्नुहोस्। दुवै असफल भए रिजोल्भर वा त्यसको मार्ग बिग्रिएको छ। केवल निजी नाम असफल भए रिजोल्भरले उत्तर दिएको छ र प्रश्न क्षेत्र वा राउटिङ बन्छ। मार्ग परिवर्तनले फरक व्याख्या गर्न नसकून् भनेर दुवै प्रश्न एक मिनेटभित्र चलाउनुहोस्।

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

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

nslookup example.com
nslookup host.corp.example 10.20.30.53

ग्राहकले साँच्चै त्यो सर्भरसम्म पुग्न सक्छ भनी पुष्टि गर्नुहोस्

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

हरेक प्लेटफर्मले यसको उत्तर एक लाइनमा दिन्छ, र आउटपुटमा उल्लेख गरिएको इन्टरफेस नै पूरा उत्तर हो। यदि यो भौतिक एडाप्टरतर्फ देखाउँछ भने र रिजोल्भर सुरुङपछाडि छ भने, प्रोफाइलले यसलाई ढाक्ने प्रिफिक्स पठाइरहेको छैन।

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

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

ब्राउजरहरूले प्रणालीको रिजोल्भरलाई बाइपास गर्न सक्छन् भनी सम्झनुहोस्

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

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

क्यास खाली गर्नुहोस् र वास्तविक काम फेरि परीक्षण गर्नुहोस्

सेटिङ सुधारेपछि स्थानीय रिजोल्भर क्यास खाली गर्नुहोस् ताकि पुरानो उत्तर सुधारभन्दा लामो बाँच्न नसकोस्। छोटो सुधारपछि फेरि असफलता भयो भने कारण अझै छ, क्यास खाली गर्न असफल भयो भन्ने होइन। तीन क्यास अलग भएकाले तपाईं जुन मेसिनमा छौ त्यससँग मिल्ने लाइन छान्नुहोस्।

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

त्यसपछि कृत्रिम खोजको सट्टा मूल काम दोहोर्याउनुहोस्, किनकि प्रयोगकर्तालाई काम नै महत्त्वपूर्ण हुन्छ। एक पटक फेरि जोडिनुहोस्, ताकि पुनःपरीक्षणले प्रयोगकर्ता साँच्चै हुने अवस्था ढाकोस्। Microsoft को nslookup सन्दर्भ प्रश्नका आर्गुमेन्टका लागि राख्न लायक पृष्ठ हो।

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