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 द्वारा स्थानीय मल्टिकास्ट प्रयोगका लागि आरक्षित छ, र यसलाई बाहिर पठाउँदा ढिलो असफलता र अनावश्यक डेटा प्रकट हुन्छ।

नाम होइन, सेवा जाँच्नुहोस्

खोज सूचीमा नाम हुनु खोजको चरण प्रमाणित गर्छ, सेवाले जवाफ दिन्छ भन्ने होइन। प्रिन्ट कतार वा वेब इन्टरफेस खोल्नुहोस् र वास्तविक कार्य पूरा गर्नुहोस्, त्यसपछि पुनः जडान भएपछि दोहोर्याउनुहोस्।

खोजले नामहरू आक्रामक रूपमा क्यास गर्छ, त्यसैले पुरानो प्रविष्टि सफलताजस्तो देखिन सक्छ। प्रमाणपत्र वा प्रमाणीकरण सङ्केत देखिएमा, त्यो अर्को तह र छुट्टै समस्या हो। तपाईंले कुन संयन्त्र बदल्नुभयो, रिजोल्भर कि खोज, लेख्नुहोस्, ताकि अर्को व्यक्तिले पूरै प्रश्न फेरि खोल्नु नपरोस्।