VPN मध्ये mDNS: .local नावे का सोडवली जात नाहीत

तुमच्या कार्यालयातील प्रिंटर तुमच्या डेस्कवरील प्रत्येक ॲपमध्ये दिसतो आणि VPN वर अदृश्य होतो, जरी तुम्ही त्याला असलेल्या माहीत असलेल्या पत्त्याला पिंग करू शकता। बोगद्यात काहीही तुटलेले नाही: शोध आणि पोहोच वेगळ्या सेवा आहेत, आणि डीफॉल्टनुसार त्यापैकी फक्त एकच राउटेड बोगदा ओलांडते। खालील तपासण्या मार्ग जोडण्यापूर्वी त्यांना वेगळे करतात। जी क्वेरी कधीही लिंक सोडली नाही ती मार्गाने दुरुस्त होऊ शकत नाही।

आज काय सोडवले जाते आणि काय फक्त सोडवलेले दिसते ते तपासा

आधी दोन प्रश्न वेगळे करा: होस्टनावासाठी unicast क्वेरी रिझोल्व्हरला विचारते, तर _ipp._tcp साठी ब्राउझ स्थानिक लिंकला विचारते। Linux वर, avahi-browse -a मल्टिकास्ट DNS काय पाहू शकते ते दाखवते, आणि resolvectl query name.local रिझोल्व्हर स्टॅक त्या नावासह काय करतो ते दाखवते। macOS वर, dns-sd -B _ipp._tcp आधी पत्त्याची गरज न ठेवता शोधलेल्या सेवांची यादी करते।

जर पत्ता उत्तर देतो आणि नाव नाही, तर राउटिंग काम करते आणि शोध काम करत नाही। .local नाव avahi-browse इन्स्टॉल नसतानाही nss-mdns मार्गे होस्टवरच उत्तर देऊ शकते, म्हणून त्या नावाला यशस्वी 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 द्वारे स्थानिक मल्टिकास्ट वापरासाठी राखीव आहे, आणि ते बाहेर पाठवल्याने संथ बिघाड आणि अनावश्यक डेटा प्रकटीकरण होते।

सेवा तपासा, नाव नाही

शोध यादीतील नाव शोधाचे पाऊल सिद्ध करते, सेवा उत्तर देते हे नाही। प्रिंट रांग किंवा वेब इंटरफेस उघडा आणि खरी क्रिया पूर्ण करा, नंतर पुन्हा कनेक्ट झाल्यावर ती पुन्हा करा।

शोध नावे आक्रमकपणे कॅश करतो, म्हणून जुनी नोंद यशासारखी दिसू शकते। प्रमाणपत्र किंवा प्रमाणीकरण सूचना दिसल्यास, तो पुढील स्तर आणि वेगळी समस्या आहे। तुम्ही कोणती यंत्रणा बदलली, रिझोल्व्हर की शोध, ते लिहून ठेवा, जेणेकरून पुढच्या व्यक्तीला पूर्ण प्रश्न पुन्हा उघडावा लागणार नाही।