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 का स्वामित्व ले। किसी भी तरह, दोबारा कनेक्ट होने से पहले और बाद में रिज़ॉल्वर सूची दर्ज करें, परीक्षण खत्म होने पर मूल मेट्रिक बहाल करें, और पुष्टि करें कि पुराना व्यवहार लौट आया है।