पोर्ट 53 पर OpenVPN: तीन बातचीतें जिन्हें लोग मिला देते हैं
एंडपॉइंट की खोज, एन्क्रिप्टेड ट्रांसपोर्ट और टनल के बाद का DNS तीन अलग बातचीतें हैं। पोर्ट या रिज़ॉल्वर बदलने से पहले पहचानें कि कौन-सा चरण विफल हुआ।
जो रिपोर्टें कहती हैं कि VPN पोर्ट 53 पर अवरुद्ध है, वे तीन ऐसी टिप्पणियाँ मिला देती हैं जो अलग-अलग कारणों से विफल होती हैं। एंडपॉइंट के नाम का समाधान किसी टनल के बनने से पहले होता है, एन्क्रिप्टेड ट्रांसपोर्ट अलग बातचीत है, और उसके बाद की जाने वाली DNS क्वेरी तीसरी है। हर एक की अपनी विफलता-पहचान है, और उनमें से केवल एक ही DNS से जुड़ी है।
कुछ भी बदलने से पहले पैकेटों को उनके उद्देश्य के अनुसार छाँटें, क्योंकि समाधान चरण का अनुसरण करता है।
तीन बातचीतें, एक पोर्ट नंबर
पहली बातचीत एंडपॉइंट के लिए नाम की खोज है: आपकी मशीन अपने कॉन्फ़िगर किए गए रिज़ॉल्वर से पूछती है कि vpn.example.com कहाँ है, और वह उत्तर सामान्य DNS पर आता है, इससे पहले कि क्लाइंट एक भी टनल पैकेट भेजे। दूसरी बातचीत स्वयं OpenVPN ट्रांसपोर्ट है, जो खोज से मिले पते पर उसी प्रोटोकॉल और पोर्ट पर जुड़ता है जो प्रोफ़ाइल बताती है। तीसरी बातचीत टनल बन जाने के बाद होती है, जब एप्लिकेशन नाम माँगते हैं और भेजी गई रिज़ॉल्वर सेटिंग्स तय करती हैं कि उत्तर कौन देगा।
ये तीनों स्वतंत्र रूप से सफल या विफल हो सकती हैं। कोई क्लाइंट अपने एंडपॉइंट का समाधान बिलकुल ठीक कर सकता है और फिर भी लिसनर तक न पहुँचे, और वह टनल स्थापित कर सकता है जबकि हर आंतरिक नाम-खोज विफल हो क्योंकि DNS सेटिंग्स कभी पहुँचीं ही नहीं।
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
तालिका को विवरण के बजाय जाँच-सूची की तरह पढ़ें। यदि एंडपॉइंट का नाम हल नहीं होता, तो आगे कुछ भी काम नहीं कर सकता, और टनल कभी शुरू नहीं होती।
पोर्ट नंबर एप्लिकेशन का नाम नहीं है
पोर्ट 53 परंपरा से DNS ढोता है, और कोई OpenVPN ऑपरेटर वहाँ लिसनर भी प्रकाशित कर सकता है, इसीलिए यह संख्या कमज़ोर पहचानकर्ता है। UDP 53 पर OpenVPN सत्र अभी भी OpenVPN सत्र ही है, और पोर्ट 53 पर सर्वर से की गई DNS क्वेरी यह नहीं बताती कि टनल की अनुमति है या नहीं। प्रोफ़ाइल की proto और remote पंक्तियाँ बाहरी एंडपॉइंट तय करती हैं; पोर्ट नंबर स्वयं कुछ भी तय नहीं करता।
निदान में यह दोनों तरफ़ काटता है: पोर्ट 53 पर सामान्य UDP प्रोब यह साबित करता है कि कोई पोर्ट उत्तर देता है, यह नहीं कि VPN सेवा उत्तर देती है। असली क्लाइंट और असली प्रोफ़ाइल के साथ परीक्षण करें, क्योंकि केवल वही उस हैंडशेक का अभ्यास करता है जिसकी सेवा अपेक्षा करती है।
नेटवर्क को दोष देने से पहले लिसनर साबित करें
सर्वर पर ss -lunp | grep 53 से जाँचें कि क्या बँधा है और उसकी तुलना प्रोफ़ाइल के प्रोटोकॉल और पोर्ट से करें। क्लाइंट के नेटवर्क से, क्लाइंट को अधिक विस्तार के साथ चलाएँ ताकि लॉग दिखाए कि उसने कौन-सा पता और ट्रांसपोर्ट आज़माया। यदि सर्वर सुन रहा है और क्लाइंट के पैकेट नहीं पहुँच रहे, तो मार्ग या नीति उन्हें अस्वीकार कर रही है, और यह नेटवर्क मालिक के साथ की बातचीत है, पोर्ट बदलने का कारण नहीं।
अलग पोर्ट तभी मदद करता है जब सेवा वास्तव में वहाँ सुनती हो और परिनियोजन अनुमति देता हो। प्रबंधित नेटवर्क की फ़िल्टरिंग से बचने के लिए लिसनर हटाना नीति का निर्णय है, समस्या-निवारण का चरण नहीं। सेवा बदलने से पहले नेटवर्क मालिक से पूछें कि क्या अनुमत है, क्योंकि नीति तोड़ने वाला रास्ता बाद में बंद कर दिया जाता है। उस उत्तर को प्रोफ़ाइल के पास लिख लें ताकि अगला व्यक्ति अनुरोध न दोहराए।
टनल के बाद DNS अलग से जाँचें
टनल बन जाने के बाद, VPN इंटरफ़ेस पर रिज़ॉल्वर की स्थिति देखें और एक आंतरिक नाम तथा एक सार्वजनिक नाम क्वेरी करें। यदि टनल ट्रैफ़िक ढो रही है और आंतरिक नाम विफल होते हैं, तो भेजी गई DNS सेटिंग्स लागू नहीं हुईं, जो क्लाइंट एकीकरण का प्रश्न है, ट्रांसपोर्ट का नहीं। यदि सार्वजनिक नाम विफल हों और आंतरिक नाम काम करें, तो स्प्लिट-टनल नीति वही कर रही है जिसके लिए उसे कॉन्फ़िगर किया गया था।
DNS परिवर्तन रिज़ॉल्वर मालिक के पास रखें। एक परीक्षण पास कराने के लिए प्रबंधित रिज़ॉल्वर कॉन्फ़िगरेशन को ओवरराइट करना मशीन पर बाकी सब के लिए निजी नाम तोड़ सकता है। यदि टनल रिज़ॉल्वर भेजती है और क्लाइंट उसे अनदेखा करता है, तो कहीं और स्थिर प्रविष्टि जोड़ने के बजाय क्लाइंट एकीकरण ठीक करें। स्थिर प्रविष्टियाँ विफलता को तब तक छिपाती हैं जब तक कोई नेटवर्क न बदले। लिख लें कि किस नामस्थान का उत्तर किस रिज़ॉल्वर से अपेक्षित है।