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>

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

यी जाँचपछि मात्र रिजोल्भर बदल्नु वा फायरवाल नीति पुनः बनाउनु अर्थपूर्ण हुन्छ। दुवै प्रमाणले समर्थन गरेभन्दा ठूला परिवर्तन हुन्।

सम्बन्धित लेखहरू