VPN के अंदर mDNS: .local नाम क्यों हल नहीं होते

आपके दफ़्तर का प्रिंटर आपकी मेज़ पर हर ऐप में दिखता है और VPN पर गायब हो जाता है, हालाँकि आप उस पते को पिंग कर सकते हैं जो आप जानते हैं उसका है। सुरंग में कुछ भी टूटा नहीं है: खोज और पहुँच अलग-अलग सेवाएँ हैं, और डिफ़ॉल्ट रूप से उनमें से केवल एक ही रूटेड सुरंग पार करती है। नीचे दी गई जाँचें रूट जोड़ना शुरू करने से पहले उन्हें अलग करती हैं। जो क्वेरी कभी लिंक नहीं छोड़ी, उसे रूट ठीक नहीं कर सकता।

जाँचें कि आज क्या हल होता है और क्या केवल हल हुआ दिखता है

पहले दो सवाल अलग करें: होस्टनाम के लिए unicast क्वेरी रिज़ॉल्वर से पूछती है, जबकि _ipp._tcp के लिए ब्राउज़ स्थानीय लिंक से पूछता है। Linux पर, avahi-browse -a दिखाता है कि मल्टीकास्ट DNS क्या देख सकता है, और resolvectl query name.local दिखाता है कि रिज़ॉल्वर स्टैक उस नाम के साथ क्या करता है। macOS पर, dns-sd -B _ipp._tcp पहले पते की ज़रूरत के बिना खोजी गई सेवाओं की सूची बनाता है।

अगर पता जवाब देता है और नाम नहीं, तो रूटिंग काम करती है और खोज नहीं। .local नाम मेज़बान पर ही nss-mdns के ज़रिए भी हल हो सकता है, भले avahi-browse इंस्टॉल न हो, इसलिए उस नाम पर सफल getent या पिंग इस बात का सबूत नहीं है कि खोज सुरंग पार कर गई; ब्राउज़ परिणाम और रिज़ॉल्वर परिणाम अलग-अलग सबूत हैं। ऐप जो खोजते हैं उसे कैश करते हैं, इसलिए विफलता अक्सर कनेक्ट होने के घंटों बाद दिखती है, कनेक्ट होते समय नहीं। ऐप बंद करके फिर खोलें, फिर देखें कि कैश प्रविष्टि में नाम है या पता, क्योंकि खोज रुकने के बहुत बाद तक पता काम करता रहता है।

क्वेरी कभी सुरंग पार क्यों नहीं करती

मल्टीकास्ट DNS क्वेरी 224.0.0.251 पर भेजता है, स्थानीय नेटवर्क नियंत्रण ब्लॉक के अंदर, UDP पोर्ट 5353 पर। राउटर उस ब्लॉक के पते फ़ॉरवर्ड नहीं करते, इसलिए क्वेरी उसी लिंक पर रहती है जहाँ भेजी गई थी। प्रेषक IP TTL या IPv6 हॉप सीमा को 255 पर सेट करते हैं ताकि प्राप्तकर्ता उस पैकेट को अस्वीकार कर सके जो पहले ही राउटर पार कर चुका है; प्रोटोकॉल इस तरह लिंक के बाहर की जालसाज़ी पकड़ता है, इस तरह नहीं कि वह स्थानीय रहता है। स्थानीयता गंतव्य पते से आती है, एक-हॉप TTL से नहीं।

सुरंग का प्रकार भी मायने रखता है। tun-शैली का इंटरफ़ेस केवल IP पैकेट ले जाता है और कुछ नहीं, इसलिए कोई मल्टीकास्ट समूह उसे पार नहीं कर पाता। tap-शैली का ब्रिज ब्रॉडकास्ट डोमेन को ही बढ़ाता है, इसलिए कुछ पुराने डिज़ाइन रूटिंग के बजाय ब्रिज करते थे, और ब्रिज जो भी समस्या लाता है वह सब विरासत में मिली।

विश्वसनीय LAN के लिए अपवाद इसमें कुछ नहीं बदलता, क्योंकि वह तय करता है कि कौन-सा ट्रैफ़िक सुरंग का उपयोग कर सकता है, सुरंग को मल्टीकास्ट फ़ॉरवर्ड करना सिखाने के बजाय। पैकेट के पास अब भी सुनने के लिए कोई साझा सेगमेंट नहीं है।

ऐसा नामकरण डिज़ाइन चुनें जिसे आप संभाल सकें

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

डिस्कवरी प्रॉक्सी या mDNS रिफ़्लेक्टर इस अंतराल को पाट सकता है, और यह अपने होस्ट, अपने एक्सपोज़र और अपनी क्लाइंट आवश्यकताओं वाला वास्तविक डिज़ाइन है। यह इसलिए नहीं दिखता कि आपने रूट जोड़ा है। कभी भी .local क्वेरी सार्वजनिक रिज़ॉल्वर को फ़ॉरवर्ड न करें: यह डोमेन RFC 6762 द्वारा स्थानीय मल्टीकास्ट उपयोग के लिए आरक्षित है, और इसे बाहर भेजने से धीमी विफलताएँ और अनावश्यक डेटा प्रकटीकरण होता है।

नाम नहीं, सेवा सत्यापित करें

खोज सूची में नाम खोज के चरण को साबित करता है, यह नहीं कि सेवा जवाब देती है। प्रिंट कतार या वेब इंटरफ़ेस खोलें और वास्तविक कार्रवाई पूरी करें, फिर दोबारा कनेक्ट होने पर उसे दोहराएँ।

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