Windows VPN DNS चुहावट: मेट्रिकले मार्गलाई किन जित्छ

एउटा क्वेरी मेसिन छोडेर घरको राउटरमा पुग्छ, जबकि हरेक प्याकेट टनेलबाट गइरहेको हुन्छ। सहज निष्कर्ष हराएको मार्ग हो, तर मार्ग सामान्यतया ठीकै हुन्छ। Windows ले इन्टरफेस मेट्रिकका आधारमा कुन इन्टरफेसको रिजोल्भरलाई सोध्ने भनेर छान्न सक्छ, र टनेल एडाप्टर यो तुलनामा वायरलेससँग प्रायः हार्छ।

एउटै चुहावटका दुई व्याख्या

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

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

मेट्रिक र रिजोल्भर सँगै तुलना गर्नुहोस्

टनेल चालु हुँदा इन्टरफेस, तिनका मेट्रिक र कन्फिगर गरिएका सर्भर लेख्नुहोस्। तिनलाई दुई छुट्टै सूची होइन, तालिकाका रूपमा पढ्नुहोस्, किनकि प्रश्न कुन रिजोल्भर पहिले आउँछ भन्ने हो, कुन रिजोल्भर अवस्थित छन् भन्ने होइन।

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

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

कुनै पनि रिजोल्भर कन्फिगर नगरिएको टनेल एडाप्टर उत्तिकै सामान्य प्रकार हो। क्लाइन्टले DNS नधकेली इन्टरफेस उठाउँछ, त्यसैले क्रमको प्रश्न नै उठ्दैन।

टनेल माथि ल्याएर फेरि जाँच्नुहोस्

एलिभेटेड शेलमा टनेल इन्टरफेसलाई सबैभन्दा कम मेट्रिक दिनुहोस्, वा भौतिक एडाप्टरको मान बढाउनुहोस्। दुवै प्रत्येक-इन्टरफेस सेटिङ हुन् र दुवै उल्टाउन सकिन्छ, जुन तपाईं अगाडि नबसेको हुन सक्ने मेसिन बदल्दा महत्त्वपूर्ण हुन्छ।

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

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

त्यसपछि एउटा आन्तरिक र एउटा सार्वजनिक नाम सोध्नुहोस् र कुन सर्भरले जवाफ दियो जाँच्नुहोस्। Microsoft को स्वचालित मेट्रिकबारे सन्दर्भ ले सबैभन्दा कम मानलाई किन प्राथमिकता मिल्छ र स्वचालित बाँडफाँट कसरी निकालिन्छ भनेर व्याख्या गर्छ।

पुनः जडानपछि पनि टिक्ने बनाउनुहोस्

हरेक जडानमा फेरि बनिने एडाप्टरमा हातले दिइएको मेट्रिक हराउने सेटिङ हो। क्लाइन्टले इन्टरफेस फेरि बनाए यो ओभरराइडका लागि जडानपछिको स्क्रिप्ट, नीति वा जडानको अवधिभर DNS को स्वामित्व लिने क्लाइन्ट कन्फिगरेसन चाहिन्छ।

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