उपकरणको छेउमा प्रिन्टर छोटो नाममा जवाफ दिन्छ र फाइल सर्भर उपनाममा जवाफ दिन्छ। सुरुङबाट दुवै नाम समयसीमा सकिन्छन्, जबकि तिनका ठेगानाहरू अझै काम गर्छन्। रुट आफ्नो काम गरिरहेको छ; ती छोटा नामहरूलाई काम गराउने नामकरण बाटोले कहिल्यै सुरुङ पार गरेन। तीन संयन्त्रहरूले यो व्यवहार उत्पन्न गर्छन्, र प्रत्येकलाई फरक सुधार चाहिन्छ।

नाम कुन संयन्त्रमा निर्भर छ भनेर पहिचान गरेर सुरु गर्नुहोस्।

फरक व्यवहार गर्ने तीन प्रकारका नामहरू

fileserver जस्तो एकल-लेबल नाम सामान्यतया रिजोल्भरले थप्ने DNS खोज सफिक्समा निर्भर हुन्छ। त्यो सफिक्स प्रायः स्थानीय DHCP लिजसँग आउँछ, त्यसैले VPN बाट ठेगाना पाउने टाढाको क्लाइन्टलाई त्यो जान्ने कुनै कारण छैन। रुट थप्दा सफिक्स पुग्दैन। छोटो नाम नामको रूपमा रहन छाड्छ, त्यसको पछाडिको ठेगाना पुग्न सकिने भए पनि।

.local मा अन्त्य हुने नाम सामान्यतया स्थानीय लिङ्कमा मल्टिकास्ट DNS द्वारा समाधान गरिन्छ, जसरी RFC 6762 वर्णन गर्छ। मल्टिकास्टले रुट गरिएको सुरुङ पार गर्दैन, जबसम्म कसैले जानाजान ब्रिज वा प्रोक्सी गर्दैन, त्यसैले तपाईंले खण्ड छोड्ने क्षणमा नाम समाधान हुन छाड्छ।

पूर्ण रूपमा योग्य कम्पनीको नाम संस्थाका रिजोल्भरहरूले सेवा दिने आन्तरिक जोन को हो। VPN ले ती रिजोल्भरहरू पुस गर्छ र क्लाइन्ट तिनलाई प्रयोग गर्न कन्फिगर गरिएको हुन्छ भने त्यो टाढाबाट काम गर्छ। र localhost RFC 6761 अनुसार विशेष-प्रयोगको हो: यसले तपाईंको अगाडिको मेसिनलाई जनाउँछ, कहिल्यै टाढाको सेवालाई होइन।

रुट बदल्नु अघि रिजोल्भर पढ्नुहोस्

कुन नाम सर्भरले जवाफ दियो र कुन सफिक्स थपियो भनेर सोध्नुहोस्। विभिन्न रिजोल्भरहरूबाट एउटै क्वेरीले फरक जवाफ दिन्छ, र त्यही फरक तपाईंलाई चाहिने प्रमाण हो।

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

यदि पूर्ण रूपमा योग्य क्वेरी समाधान हुन्छ तर छोटो हुँदैन भने, खराबी सफिक्समा छ, सर्भरमा होइन। यदि कुनै पनि समाधान हुँदैन र ठेगाना काम गर्छ भने, क्लाइन्टले आन्तरिक रिजोल्भर प्रयोग नै गर्दैन। रिजोल्भर सूचीको तुलना VPN ले पुस गर्नुपर्नेसँग गर्नुहोस्, किनकि प्रत्येक क्वेरीका लागि आफ्नै स्थानीय रिजोल्भर राख्ने क्लाइन्टले आन्तरिक जोन कहिल्यै देख्ने छैन।

सही नाम क्लाइन्टसम्म पुर्याउनुहोस्

प्रशासकबाट दस्तावेजीकृत टाढा-पहुँच नाम पूरै माग्नुहोस् र सफिक्स अनुमान गर्नुको सट्टा प्रोफाइलमा त्यही प्रयोग गर्नुहोस्। यदि परिनियोजनले split DNS समर्थन गर्छ भने, आन्तरिक डोमेन आन्तरिक सर्भरहरूले समाधान गर्ने गरी कन्फिगर गर्नुहोस्, बाँकी सबैले स्थानीय रिजोल्भर राख्नेछ। क्लाइन्टले समर्थन गर्ने ठाउँमा VPN कन्फिगरेसनमार्फत खोज डोमेन पुस गर्नुहोस्।

नतिजा क्लाइन्टमा जाँच्नुहोस्, गेटवेमा होइन। सर्भरमा लागू गरिएको र क्लाइन्टसम्म कहिल्यै नपुग्ने सेटिङले केही बदल्दैन।

प्रमाणपत्रको पहिचान अक्षुण्ण राख्नुहोस्

प्रमाणपत्रको त्रुटि बेवास्ता गर्ने ठेगाना-आधारित परीक्षणले सकेट खुल्यो भन्ने मात्र प्रमाणित गर्छ। सेवाको प्रमाणपत्र एक नामका लागि जारी गरिन्छ, र क्लाइन्टले उचित कारणले बेमेल अस्वीकार गरिरहनेछ। यदि प्रमाणपत्रले आन्तरिक नाम मात्र सूचीबद्ध गर्छ भने, त्यही नाम प्रयोग गर्नुहोस् र समाधान सुधार्नुहोस्, वा तपाईंले प्रयोग गर्न खोजेको ठेगाना समेट्ने प्रमाणपत्र लिनुहोस्।

जसले सफल जडान दियो त्यो नाम, रिजोल्भर र सफिक्स नोट गर्नुहोस्। त्यो अभिलेखले अर्को व्यक्तिलाई साँचो समस्या लुकाउने ठेगाना-आधारित वैकल्पिक उपाय दोहोर्याउनबाट बचाउँछ।

सम्बन्धित लेखहरू