तपाईंको /etc/hosts प्रविष्टि VPN को DNS सम्म किन पुग्दैन

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

Hosts स्थानीय ओभरराइड हो, जोन अपडेट होइन

फाइल भनेको नाम-सेवा लाइब्रेरीहरूले DNS सर्भरलाई सोध्नुअघि वा त्यसको सट्टामा हेर्ने म्यापिङको सूची हो। 10.40.0.20 build.corp.example जस्तो लाइनले त्यो एउटै मेसिनका अनुप्रयोगहरूले के निष्कर्ष निकाल्छन् त्यो बदल्छ। यसले रेकर्ड बनाउँदैन, सुरुङबाट यात्रा गर्दैन, र सुरुङले देखाउने DNS सर्भरलाई यसको अस्तित्वको कुनै जानकारी हुँदैन।

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

दुई आदेश, दुई फरक कम्पोनेन्ट

यो बहस रोक्ने सबैभन्दा छिटो तरिका भनेको फरकलाई दुई आदेशमा देखिने बनाउनु हो, दुवै hosts प्रविष्टि भएको क्लाइन्टमा चलाइन्छ:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

पहिलोले प्रणालीको आफ्नै लुकअप मार्गलाई सोध्छ, जसले सामान्य glibc प्रणालीमा DNS अघि स्थानीय फाइलहरू पढ्छ। दोस्रोले त्यो ठेगानाको सर्भरमा सिधै DNS क्वेरी पठाउँछ र स्थानीय फाइलहरू पटक्कै हेर्दैन। पहिलोले तपाईंको प्रविष्टि फर्काउँदा र दोस्रोले NXDOMAIN फर्काउँदा, रेकर्ड DNS मा अवस्थित छैन र तपाईंको मेसिन स्थानीय ओभरराइडबाट उत्तर दिइरहेको छ भनी तपाईंले प्रमाणित गर्नुभयो।

क्रम कन्फिगर गर्न सकिन्छ, र कुनै विशेष वितरणबारे केही निष्कर्ष निकाल्नुअघि यो जाँच्न लायक छ। /etc/nsswitch.conf मा hosts: लाइन हेर्नुहोस्; hosts: files dns पहिले फाइलहरू हेर्छ। केवल क्रम बदल्नका लागि त्यो उदाहरणलाई काम गरिरहेको कन्फिगरेसनमा प्रतिलिपि नगर्नुहोस्, किनभने वास्तविक प्रणालीहरूले उदाहरणमा नभएका थप स्रोत र सर्तसापेक्ष सेवा प्रविष्टिहरू प्रायः सूचीबद्ध गर्छन्।

systemd-resolved ले परीक्षण धमिलो बनाउँछ

systemd-resolved प्रयोग गर्ने प्रणालीमा स्थानीय स्टबले hosts डेटाबेसबाट पनि नामहरू उपलब्ध गराउँछ। त्यसैले 127.0.0.53 लाई क्वेरी गर्नु दूरस्थ सर्भरको स्वतन्त्र परीक्षण होइन, यद्यपि यो DNS क्वेरी जस्तो देखिन्छ र त्यस्तै व्यवहार गर्छ। रिजोल्भरले के जान्छ र कुन सर्भरहरूलाई सोध्छ भनी तपाईं यसबाट पुष्टि गर्न सक्नुहुन्छ:

resolvectl query build.corp.example
resolvectl status

status आउटपुटले प्रत्येक लिङ्कका लागि DNS सर्भरहरू नाम दिन्छ, र यसरी तपाईं VPN लिङ्कले रिजोल्भर पायो कि पाएन भनी थाहा पाउनुहुन्छ। त्यो प्रश्न hosts प्रविष्टिबाट अलग छ र निजी नाम एक जनालाई होइन सबै प्रयोगकर्तालाई असफल हुँदा सोध्न लायक प्रश्न त्यही हो।

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

VPN भरि नाम वास्तवमा केले बाँड्छ

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

hosts फाइलहरू वितरण गर्नु वैध विकल्प हो, र यो नाम-सेवा होइन, इन्डपोइन्ट व्यवस्थापन हो। यदि तपाईंले यो रोज्नुभयो भने, फाइल फ्लीट व्यवस्थापन गर्नेले तैनाथ, संस्करणबद्ध र हटाउनुपर्छ, र डिजाइनमा त्यसै गरी वर्णन गर्नुपर्छ। “VPN ले यो सम्हाल्छ” त्यो प्रक्रियाको वर्णन होइन।

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

रिजोल्भ भएको नाम मार्ग होइन

नाम रिजोल्युसन र पहुँचयोग्यता फरक कुरा हुन्, र पुरानो स्थानीय म्यापिङ तिनलाई गलाउने उत्कृष्ट तरिका हो। सरेको ठेगानातिर देखाउने hosts प्रविष्टिले DNS सुधारिएपछि पनि लामो समय पुरानै होस्ट छानिरहनेछ, र लक्षण राम्ररी रिजोल्भ हुने नाममा राउटिङ असफलता जस्तो देखिन्छ।

त्यसैले जब प्रतिवेदन “नाम रिजोल्भ हुन्छ तर सेवा पहुँचयोग्य छैन” हुन्छ, प्रणाली लुकअपलाई VPN DNS सर्भरमा गरिएको स्पष्ट क्वेरीसँग तुलना गर्नुहोस्, त्यसपछि पाएको ठेगानालाई सेवाले वास्तवमा प्रयोग गर्ने ठेगानासँग जाँच्नुहोस्। systemd-resolved सन्दर्भ ले यसले हेर्ने स्थानीय स्रोतहरूको दस्तावेजीकरण गर्छ, र त्यो तुलनाका लागि चाहिने नक्सा यही हो।

त्यसपछि ओभरराइडलाई यसको मालिकमार्फत सुधार्नुहोस्। आफ्नै hosts फाइलबाट एउटा लाइन हटाउँदा तैनाथी स्क्रिप्टबाट त्यही लाइन पाएका ती बाह्र ल्यापटपहरूका लागि केही हुँदैन, र मानिसहरूसँग वास्तवमा भएको यो समस्याको संस्करण त्यही हो।