OpenVPN DNS भेजता है, पर आपका रिज़ॉल्वर इसे कभी न देखे

क्लाइंट लॉग भेजा गया DNS सर्वर दिखाता है, टनल जुड़ी है, और कोई आंतरिक नाम फिर भी किसी चीज़ में हल नहीं होता। भेजने में अपने आप में कुछ टूटा नहीं है। विकल्प पहुँच गया और ऑपरेटिंग सिस्टम के रिज़ॉल्वर ने उसका कभी उपयोग नहीं किया, क्योंकि ज़्यादातर Unix क्लाइंट पर OpenVPN मान सौंप देता है और एप्लिकेशन को प्लेटफ़ॉर्म पर छोड़ देता है।

लक्षण: लॉग DNS दिखाता है और नाम अब भी विफल होते हैं

OpenVPN dhcp-option DNS और डोमेन जानकारी ढोता है, और क्लाइंट दर्ज करता है कि उसे क्या मिला। कुछ कार्यान्वयनों में क्लाइंट वे सेटिंग्स भीतर ही लागू करता है; दूसरों में वह उन्हें किसी एकीकरण स्क्रिप्ट या नेटवर्किंग सेवा के लिए निर्यात करता है। लॉग पंक्ति कहानी का केवल पहला आधा हिस्सा बताती है। दूसरा आधा कहीं ऐसी जगह होता है जिसे क्लाइंट नियंत्रित नहीं करता। आम तौर पर विफलता वहीं रहती है।

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

प्राप्त होना लागू होना नहीं है

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

यह मानने के बजाय कि हर Unix क्लाइंट वही फ़ाइल फिर से लिखता है, कार्यान्वयन के समर्थित एकीकरण की जाँच करें। यही धारणा लोगों को ऐसी रिज़ॉल्वर कॉन्फ़िगरेशन संपादित करने पर मजबूर करती है जिसे कुछ भी नहीं पढ़ता।

हर प्लेटफ़ॉर्म पर रिज़ॉल्वर का मालिक खोजें

Windows पर नाम रिज़ॉल्यूशन नीति तालिका कुछ प्रत्ययों को कुछ सर्वरों की ओर भेज सकती है, और VPN क्लाइंट वहाँ नियम स्थापित कर सकता है। केवल एडाप्टर की DNS सूची नहीं, नीति जाँचें। Linux पर NetworkManager या systemd-resolved कॉन्फ़िगरेशन के मालिक हो सकते हैं, और इनमें से कौन मालिक है यह तय करता है कि पुनः कनेक्शन क्या सुरक्षित रखेगा।

वास्तविक स्थिति उस उपकरण से पढ़ें जो सचमुच प्रश्नों का उत्तर देता है: systemd-resolved होस्ट पर resolvectl query internal.example.net, या प्लेटफ़ॉर्म का समतुल्य। फिर उस उत्तर की तुलना उस DNS सर्वर से करें जिसे क्लाइंट लॉग भेजने का दावा करता है।

ऐसी कई सेवाएँ चलाने से बचें जो बिना तालमेल के रिज़ॉल्वर सेटिंग्स को ओवरराइट करती हैं। दो मालिक ऐसा परिणाम देते हैं जो रुक-रुक कर दिखता है, और हर पुनः कनेक्शन उसे बेतरतीब ढंग से ठीक या बिगाड़ता प्रतीत होता है।

स्क्रिप्ट और foreign_option

OpenVPN भेजे गए विकल्पों को foreign_option_N नाम के चरों के ज़रिए स्क्रिप्ट में निर्यात करता है, और स्क्रिप्ट उन्हें रिज़ॉल्वर कमांड में अनुवादित कर सकती है। यह व्यवस्था समर्थित एकीकरण है, स्वचालित व्यवहार नहीं, और इसे क्लाइंट पर स्थापित और आह्वान करना होता है।

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

लॉग नहीं, नाम परखें

कनेक्ट होने के बाद क्लाइंट से केवल-आंतरिक होस्टनाम पूछें, फिर सार्वजनिक नाम पूछें, फिर देखें कि किस सर्वर ने उत्तर दिया। काम करने वाले सेटअप में दोनों उत्तर अलग-अलग जगहों से आते हैं, और दोनों डिज़ाइन से मेल खाने चाहिए।

अगर नाम हल होता है पर सेवा विफल होती है, तो DNS फिर बदलने के बजाय रूटिंग और एप्लिकेशन एक्सेस की ओर बढ़ें। OpenVPN मैनुअल dhcp-option और स्क्रिप्ट वातावरण का दस्तावेज़ीकरण करता है; दूसरी रिज़ॉल्वर फ़ाइल संपादित करने से पहले यह पुष्टि करने के लिए इसका उपयोग करें कि आपके क्लाइंट को क्या लागू करना चाहिए।