रूटेड OpenVPN टनल पर नाम की खोज क्यों विफल होती है

मेज़बान पते से ping का जवाब देता है और नाम से हर खोज में विफल होता है। टनल चालू है और रूट मौजूद है, इसलिए स्वाभाविक निष्कर्ष यह है कि VPN गलत कॉन्फ़िगर है। अधिक उपयोगी निष्कर्ष यह है कि खोज कभी रूट होने योग्य ही नहीं थी: रूटेड टनल unicast IP ढोती है, जबकि वह क्वेरी एक ब्रॉडकास्ट थी जो दूसरी तरफ़ मौजूद न हो ऐसे सेगमेंट को खोज रही थी। परतों का यह असंगत होना दिखते ही उपाय अपने आप लागत के क्रम में लग जाते हैं।

भ्रम: टनल टूटी है क्योंकि नाम विफल होते हैं

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

इसे टनल की खराबी मानने से प्रोफ़ाइल में ऐसे बदलाव होते हैं जो मदद नहीं कर सकते। विकल्प जोड़ने, एन्क्रिप्शन बदलने या क्लाइंट फिर से इंस्टॉल करने से ब्रॉडकास्ट ठीक वहीं रहता है जहाँ था।

उपाय का नाम लेने से पहले उस तंत्र का नाम लें जो विफल हुआ। ब्रॉडकास्ट वाली खोज को सेगमेंट चाहिए, जबकि रिज़ॉल्वर वाली खोज को पूछने के लिए पता चाहिए।

TUN क्या ढोती है और क्या नहीं

TUN उपकरण एक IP इंटरफ़ेस है, और यही उसे रूट होने योग्य बनाता है। OpenVPN क्लाइंट को एक पता और रूट का समूह देती है, और उसके बाद क्लाइंट साथी को डेटाग्राम भेजता है। उस मॉडल में कुछ भी ऐसा साझा लिंक नहीं बनाता जहाँ हर मेज़बान हर फ़्रेम सुने।

खोज का ट्रैफ़िक उस मॉडल में बिलकुल फ़िट नहीं होता। Windows की पुरानी नाम-क्वेरी, SSDP घोषणाएँ और mDNS अनुरोध एक ही गंतव्य के बजाय सेगमेंट में सबको भेजे जाते हैं। रूटेड लिंक के पास भेजने के लिए कोई «सब» नहीं होता। इनमें से हर तंत्र साझा माध्यम मान लेता है।

इसलिए टनल स्वस्थ हो सकती है जबकि खोज पूरी तरह विफल हो। जब कोई बताए कि VPN डाउन है, तब इसी वाक्य को पकड़े रखना है।

ब्रिजिंग सीमा हटाकर काम करती है

TAP उपकरण फ़्रेम ढोता है, और ब्रिज उसे असली LAN सेगमेंट से जोड़ देता है। तब क्लाइंट के पास उस सेगमेंट पर पता होता है और वह उसका ब्रॉडकास्ट ट्रैफ़िक सुनता है। इसीलिए ब्रिजिंग नाम की समस्या का इलाज लगती है। यह क्लाइंट को पता देने के लिए उस सेगमेंट पर निर्भर भी बना देती है।

इलाज रूटिंग सीमा हटाना है, टनल के भीतर नामकरण की कोई नई क्षमता नहीं। सेगमेंट जो ब्रॉडकास्ट करता है, अब वह लिंक भी पार करता है।

छोटी लैब के लिए यह उचित सौदा है। फैले हुए कर्मचारी-वर्ग के लिए ऐसा कम ही होता है।

DNS और WINS पुश करना संकीर्ण उपाय है

क्लाइंट को पूछने की एक निश्चित जगह दें। dhcp-option DNS और dhcp-option DOMAIN आंतरिक नामों को उस सर्वर की ओर भेजते हैं जो ज़ोन जानता है, और NetBIOS पर अब भी निर्भर Windows क्लाइंट उसी तरह WINS सर्वर पा सकता है। टनल रूटेड रहती है और सेगमेंट अपनी जगह पर रहता है।

दो शर्तें तय करती हैं कि यह काम करेगा या नहीं। बताए गए सर्वर को ज़ोन के लिए जवाब देना होगा, और क्वेरी को टनल से गुज़रने की अनुमति होनी चाहिए।

रिज़ॉल्वर को क्लाइंट से जाँचें, सर्वर की अपनी शेल से नहीं। स्थानीय रूप से काम करने वाला रिज़ॉल्वर टनल क्या ढोती है, इस बारे में कुछ नहीं कहता।

पता करें कौन-सी परत विफल हुई

पहले पते को ping करें, फिर नाम रिज़ॉल्व करें और पढ़ें कि किस सर्वर ने जवाब दिया। जो सर्वर ज़ोन होस्ट नहीं करता, उसका नकारात्मक जवाब उस क्वेरी से अलग दिखता है जो कभी मशीन से नहीं निकली। जो नाम रिज़ॉल्व होता है पर कनेक्शन ठुकराता है, वह पूरी तरह तीसरी समस्या है।

मल्टीकास्ट उसी दीवार के पीछे है। 224.0.0.251 जैसा समूह डिफ़ॉल्ट रूप से रूटेड टनल से नहीं गुज़रता, और समूह के लिए रूट मल्टीकास्ट-समझदार रास्ते या LAN पर रिफ़्लेक्टर के बिना काफ़ी नहीं है।