Windows पर OpenVPN कनेक्ट होने के बाद DNS काम करना क्यों बंद कर देता है

ping का जवाब रिज़ॉल्वर अब भी देता है जबकि पोर्ट 53 कहीं नहीं पहुँचता। देखें कि block-outside-dns फ़िल्टर कर रहा है या नहीं, फिर ऐसा रिज़ॉल्वर दें जहाँ तक टनल पहुँच सके।

ऑफ़िस के रिज़ॉल्वर को ping का जवाब "OpenVPN" कनेक्ट होने के बाद भी मिलता है, और फिर भी हर नाम-खोज विफल हो जाती है। पता पहुँच-योग्य है जबकि पोर्ट नहीं, यह संयोजन तब समझ में आता है जब आप जानते हैं कि Windows एडाप्टर के अनुसार DNS फ़िल्टर कर सकता है। प्रोफ़ाइल में block-outside-dns होने पर वही फ़िल्टर पहला संदिग्ध है और रूट तालिका देखने की ग़लत जगह है। नीचे के दो परीक्षण परतों को सेकंडों में अलग कर देते हैं।

पहुँच-योग्य पता, मृत पोर्ट

सफल ping साबित करता है कि होस्ट चालू है और कोई मार्ग मौजूद है। यह पोर्ट 53 तक पहुँचने की अनुमति के बारे में कुछ नहीं कहता, क्योंकि संबंधित फ़िल्टर दूसरी परत पर काम करता है और एडाप्टर पर निर्भर करता है। इसीलिए वही मशीन ICMP का जवाब दे सकती है और उसी पते पर भेजी गई हर क्वेरी को अस्वीकार कर सकती है। कोई भी कॉन्फ़िगरेशन बदलने से पहले दोनों परीक्षण एक ही सत्र में चलाएँ।

ping <resolver-ip>
nslookup <name> <resolver-ip>

यही जोड़ी निदान है। सबनेट तक सामान्य ट्रैफ़िक चलता रहता है जबकि नाम-समाधान मर जाता है, और लोग निष्कर्ष निकालते हैं कि सर्वर ख़राब है या DNS कभी भेजा ही नहीं गया। दोनों व्याख्याओं का पीछा करना महँगा है, और सबूत किसी संकीर्ण जगह की ओर इशारा करते हैं। किसी सेटिंग को छूने से पहले जोड़ी की पुष्टि करें।

यह विकल्प फ़िल्टरिंग प्लेटफ़ॉर्म का नियम है

OpenVPN का संदर्भ block-outside-dns को Windows Filtering Platform का प्रतिबंध बताता है जो अनुप्रयोगों को टनल के बाहर के एडाप्टरों पर DNS तक पहुँचने से रोकता है। यह TCP और UDP पोर्ट 53 को कवर करता है। चूँकि फ़िल्टर सामान्य फ़ायरवॉल नियम-सूची में नहीं बल्कि WFP में रहता है, कहीं और अनुमति नियम जोड़ने से परिणाम ज़रूरी नहीं बदलता। इसीलिए DNS की अनुमति देने की आम सलाह विफल होती रहती है।

सेटिंग आयातित प्रोफ़ाइल से या सर्वर से आ सकती है, और जिस फ़ाइल को आपने आख़िरी बार संपादित किया वह "इस बात का सबूत नहीं है कि क्लाइंट ने क्या लोड किया"। प्रभावी कॉन्फ़िगरेशन और कनेक्शन लॉग साथ पढ़ें। यह विकल्प Windows-विशिष्ट भी है, और इसे पोर्टेबल मानने से ऐसी सलाह बनती है जो लागू नहीं होती।

अधिक नियम जोड़ने के बजाय उस क्लाइंट घटक को खोजें जिसके पास यह प्रतिबंध है। मालिक वही चीज़ है जो इसे वास्तव में हटा सकती है।

फ़िल्टर रिज़ॉल्वर नहीं है

टनल के बाहर ट्रैफ़िक रोकना उसके अंदर काम करने वाला रिज़ॉल्वर स्थापित नहीं करता। यह विकल्प एक मार्ग हटा देता है और टनल का DNS कॉन्फ़िगरेशन उसी पर छोड़ देता है जिसने प्रोफ़ाइल बनाई। जिस प्रोफ़ाइल ने कभी रिज़ॉल्वर नहीं भेजा उसके पास अब कोई नहीं है।

तीन जाँच क्रम से करें। पहला, विफल अनुप्रयोग वास्तव में कौन-सा रिज़ॉल्वर इस्तेमाल करता है। दूसरा, क्या क्लाइंट ने VPN DNS सेटिंग लागू की। तीसरा, कौन-सा इंटरफ़ेस उस रिज़ॉल्वर तक ट्रैफ़िक ले जाता है।

  1. प्रयुक्त रिज़ॉल्वर: Resolve-DnsName -Server <resolver-ip> <name> की तुलना उन DNS सर्वरों से करें जिन्हें ipconfig /all सूचीबद्ध करता है।
  2. VPN DNS लागू: उसी ipconfig /all आउटपुट में टनल एडाप्टर की DNS प्रविष्टियाँ देखें।
  3. प्रयुक्त इंटरफ़ेस: Find-NetRoute -RemoteIPAddress <resolver-ip> उस गंतव्य के लिए आउटगोइंग इंटरफ़ेस बताता है।

इस नीति के अंतर्गत LAN रिज़ॉल्वर डिज़ाइन से ही अगम्य हो जाता है, तब भी जब अन्य LAN ट्रैफ़िक चल रहा हो। यही वह विकल्प है जो अपना काम कर रहा है। यदि डिज़ाइन को VPN DNS चाहिए तो रिज़ॉल्वर पंजीकरण और टनल मार्ग ठीक करें; यदि स्थानीय अपवादों के साथ split DNS चाहिए तो कॉन्फ़िगरेशन के मालिक को वे अपवाद समर्थित तरीके से व्यक्त करने होंगे।

यह विकल्प क्या कवर नहीं करता

पोर्ट 53 पूरा नाम-समाधान नहीं है। DNS over HTTPS और DNS over TLS अलग ट्रांसपोर्ट इस्तेमाल करते हैं, और कुछ अनुप्रयोग सिस्टम सेटिंग की परवाह किए बिना अपना रिज़ॉल्वर तर्क चलाते हैं। इसलिए ब्राउज़र नाम हल कर सकता है जबकि कमांड लाइन नहीं कर सकती।

इस अंतर को विरोधाभास नहीं, निदान मानें। सिस्टम रिज़ॉल्वर ख़राब है यह तय करने से पहले दोनों की तुलना करें।

लिखते समय निष्कर्ष संकीर्ण रखें। यह विकल्प एक प्लेटफ़ॉर्म पर एक ट्रांसपोर्ट सीमित करता है, और समाधान मार्ग का बाक़ी हिस्सा अपने मालिक वाला अलग डिज़ाइन प्रश्न है।

डिस्कनेक्ट से पहले और बाद की स्थिति जाँचें

कनेक्शन के दौरान वही खोज चलाएँ और मालिक क्लाइंट के डिस्कनेक्ट होने के बाद फिर चलाएँ। टनल चालू रहने पर पहला बाहरी रिज़ॉल्वर के लिए विफल होना चाहिए, और फ़िल्टर हटने पर दूसरा सफल होना चाहिए। यदि डिस्कनेक्ट के बाद भी विफल रहे तो फ़िल्टर साफ़ नहीं हुआ।

ipconfig /displaydns
nslookup <name> <resolver-ip>

क्लाइंट सेवा या मशीन को पुनः आरंभ करने से आम तौर पर पुराना फ़िल्टर साफ़ हो जाता है। यह निदान की पुष्टि करता है पर स्थायी सुधार साबित नहीं करता। जो देखा उसे दर्ज करें, क्योंकि डिस्कनेक्ट झेलने वाला फ़िल्टर फिर वही करेगा, और वही रिकॉर्ड बग रिपोर्ट को उचित ठहराता है।

इन जाँचों के बाद ही रिज़ॉल्वर बदलना या फ़ायरवॉल नीति फिर से बनाना अर्थपूर्ण है। दोनों सबूत जितना समर्थन देते हैं उससे बड़े बदलाव हैं।

संबंधित लेख