Windows वर OpenVPN कनेक्ट झाल्यानंतर DNS काम करणे का थांबते

पोर्ट 53 कुठेही पोहोचत नसतानाही रिझोल्व्हर ping ला उत्तर देत राहतो। 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> ची ipconfig /all मध्ये सूचीबद्ध DNS सर्व्हरशी तुलना करा।
  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>

क्लायंट सेवा किंवा मशीन पुन्हा सुरू केल्याने सहसा जुना फिल्टर साफ होतो। हे निदानाची पुष्टी करते पण कायमस्वरूपी दुरुस्ती सिद्ध करत नाही। जे पाहिले ते नोंदवा, कारण डिस्कनेक्ट टिकून राहणारा फिल्टर पुन्हा तसेच करेल, आणि तीच नोंद बग अहवालाचे समर्थन करते।

या तपासण्यांनंतरच रिझोल्व्हर बदलणे किंवा फायरवॉल धोरण पुन्हा बांधणे अर्थपूर्ण ठरते। दोन्ही पुरावे जितके समर्थन देतात त्यापेक्षा मोठे बदल आहेत।

संबंधित लेख