VPN DNS काम गर्छ, तर .local नामहरू अझै असफल हुन्छन्: तिनीहरूलाई कसले समाधान गर्छ?

एउटै VPN मा दुई मेसिन, एउटै होस्टनाम, र तीमध्ये एउटाले मात्र यसलाई समाधान गर्छ: फरक सामान्यतया टनेलमा होइन, तर कुन रिजोल्भरले जवाफ दियो भन्नेमा हुन्छ। Linux डेस्कटपमा त्यो नाम नाम सेवा स्विचबाट, systemd-resolved को स्टबबाट, वा एप्लिकेसनले साथै ल्याएको रिजोल्भरबाट जान सक्छ, र तीमध्ये प्रत्येकले एउटै सफिक्समा आफ्नै नियम लागू गर्छ। नियमहरू सफिक्समै छुट्टिन्छन्, किनकि .local तटस्थ लेबल होइन। कुनै कुरा कुन क्रममा चल्छ भन्ने परिवर्तन गर्नुअघि असफल प्रोग्रामले वास्तवमा कुन मार्ग लिन्छ भनी पत्ता लगाउनुहोस्।

दुई रिजोल्भर, दुई फरक जवाफ

परम्परागत glibc खोजी nsswitch.conf को hosts: लाइनबाट जान्छ र एउटाले जवाफ नदिएसम्म प्रत्येक मोड्युललाई पालैपालो सोध्छ। स्टब लिसनरमार्फत systemd-resolved सँग कुरा गर्ने क्लाइन्टले त्यसको सट्टा एउटै प्रक्रियालाई सोध्छ, र त्यो प्रक्रियाले प्रत्येक लिङ्कको नीति र आफ्नै विशेष केसहरू लागू गर्छ। आफ्नै रिजोल्भर ल्याउने वा त्यसो गर्ने पुस्तकालय लिङ्क गर्ने एप्लिकेसनले दुवैलाई बाइपास गर्न सक्छ। त्यसैले एउटै होस्टनामका एउटै मेसिनमा तीन मालिक हुन सक्छन्, र तीमध्ये एउटालाई मात्र VPN ले के चाहन्थ्यो भन्ने थाहा हुन्छ।

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

कुन आदेशले वास्तवमा तपाईंको रिजोल्भरलाई सोध्यो

दुई पढ्ने-मात्र आदेशहरू सम्बन्धित प्रश्नको जवाफ दिन्छन्, र तिनको तुलनाले कन्फिगरेसन पढ्नुभन्दा छिटो समस्या स्थानीयकरण गर्छ। वास्तविक आन्तरिक नाम प्रयोग गर्नुहोस् र आउटपुट निजी राख्नुहोस्, किनकि आन्तरिक अभिलेख आन्तरिक नै रहन्छन्। दुवैलाई असफल प्रोग्राम चल्ने त्यही सत्रमा चलाउनुहोस्:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

पहिलोले कन्फिगर गरिएका मोड्युलहरूमार्फत सोध्छ, सामान्य प्रोग्रामले यही अनुभव गर्छ। दोस्रोले सिधै systemd-resolved लाई सोध्छ र जवाफ दिने लिङ्क, प्रोटोकल र सर्भर रिपोर्ट गर्छ। सर्भरलाई ठेगानाद्वारा सोध्नुले सर्भरसँग अभिलेख छ भन्ने मात्र प्रमाणित गर्छ, किनकि एप्लिकेसनले कहिल्यै सोध्यो कि भन्नेबारे यसले केही भन्दैन। VPN बोक्ने लिङ्क र त्यसले दाबी गर्ने डोमेनहरू पढ्नुहोस्, त्यसपछि त्यो सूचीलाई असफल नामको सफिक्ससँग तुलना गर्नुहोस्।

किन .local ले तपाईंको unicast जोन छोड्छ

systemd-resolved को सन्दर्भ भन्छ कि .local मा अन्त्य हुने बहु-लेबल नामहरू, mDNS सक्षम हुँदा सामान्य unicast DNS को सट्टा सामान्यतया multicast DNS मा जान्छन्। RFC 6762 ले त्यो नामस्थान link-local multicast का लागि छुट्याउँछ, त्यसैले कर्पोरेट जोनसँग सही अभिलेख हुन सक्छ जुन त्यो सफिक्सका लागि कहिल्यै सोधिँदैन। टनेलले रिजोल्भरलाई पूर्ण रूपमा राउट गर्न सक्छ र तैपनि दौड हार्न सक्छ। क्यासबाट सफल ping ले भर्खरै भएको खोजीबारे केही भन्दैन।

एउटा अभिलेखित अपवाद छ, र यसले यी धेरैजसो केस समाधान गर्छ: जब लिङ्कले त्यो सफिक्सलाई खोज डोमेन वा राउटिङ डोमेन घोषणा गर्छ, डेमनले यसलाई unicast मार्गमा राख्छ र multicast विशेष केस छोड्छ। यो प्रत्येक लिङ्कको नीति हो, विश्वव्यापी प्राथमिकता होइन। एउटै VPN सर्भर भएका दुई मेसिन फरक व्यवहार गर्न सक्छन् जब एउटा नेटवर्क प्रोफाइलले डोमेन घोषणा गर्छ र अर्कोले गर्दैन, त्यसैले सम्झनामा भएको प्रोफाइल होइन, सक्रिय प्रोफाइल पढ्नुहोस्।

साँघुरो अपवादले विश्वव्यापी पुनर्क्रमलाई हराउँछ

तपाईंले नाम बदल्न नसक्ने अवस्थित जोनका लागि, रिजोल्भर र VPN मालिकहरूलाई त्यो डोमेन यसलाई बोक्ने जडानमा घोषणा गर्न लगाउनुहोस्। त्यो एउटा सफिक्सका लागि राउटिङ-डोमेन प्रविष्टि र इच्छित सर्भर ठेगाना नामित मालिकसहितको सानो परिवर्तन हो, र यो हातले सम्पादित फाइलमा होइन, लिङ्कसँगै बस्छ।

यो विच्छेदपछि पनि टिक्छ, किनकि लिङ्क फर्किएपछि लिङ्क नीति फेरि लागू हुन्छ। साझा nsswitch.conf सम्पादन गर्नु लोभ्याउने र महँगो विकल्प हो, किनकि यसले मेसिनमा भएका हरेक नामका लागि खोजी व्यवहार बदल्छ, स्थानीय खोजी सहित। multicast डेमन अक्षम गर्नु पनि समान होइन: यसले स्थानीय व्यवहार हटाउँछ तर कुनै पनि रिजोल्भरलाई कर्पोरेट जोन सिकाउँदैन। सेवा उत्तराधिकारमा नभई नयाँ भए, यसलाई तपाईंको संस्थाले नियन्त्रण गर्ने उपडोमेनमुनि राख्नुहोस् र प्रतिस्पर्धा पूर्ण रूपमा छोड्नुहोस्। नाम फर्मवेयरमा स्थिर भएको वा लेबलमा छापिएको भए साँघुरो अपवाद छान्नुहोस्, र क्लाइन्ट अझै तपाईंको नियन्त्रणमा भए नयाँ उपडोमेन छान्नुहोस्।

परिवर्तनपछि के प्रमाणित गर्ने

सुधार एप्लिकेसनको आफ्नै खोजीले प्रमाणित गर्नुहोस्, परीक्षणका लागि स्थापना गरेको उपकरणले होइन, र यसको तर्फबाट जवाफ दिन सक्ने क्यास खाली गर्नुहोस्। त्यसपछि रिजोल्भर मार्ग र जवाफ दिने लिङ्क पुष्टि गर्नुहोस्। अन्तमा स्थानीय खोजी परिवर्तनअघि जस्तै व्यवहार गर्छ कि जाँच्नुहोस्, किनकि देखिन छाड्ने प्रिन्टर त्यही भाग हो जो मानिसहरूले सबैभन्दा पछि याद गर्छन्। यी तीन आदेशले नाम, मार्ग र TLS पहिचान यही क्रममा जाँच्छन्:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

गलत प्रमाणपत्रसहित सही ठेगानाले कडा क्लाइन्टलाई अझै असफल बनाउँछ, त्यसैले समाधान चलेपछि एप्लिकेसनले अपेक्षा गर्ने नाम जाँच्नुहोस्। सेवाले कार्यालय दायराबाट मात्र होइन, VPN ठेगानाबाट पनि जडान स्वीकार गर्छ भनी पुष्टि गर्नुहोस्। डोमेन दायरा, सर्भर र मालिक जडानको कागजातमा लेख्नुहोस्। नत्र यो असफलता भेट्ने अर्को व्यक्तिले तपाईंले भर्खरै छलेको त्यही विश्वव्यापी सम्पादन गर्नेछ।