VPN मा आन्तरिक होस्टनामहरू dig मा किन हल हुन्छन् तर curl मा असफल हुन्छन्
dig जवाफ दिन्छ, तर curl होस्ट हल गर्न नसकेको जानकारी दिन्छ। दुई खोज शृंखला तुलना गर्नुहोस्, त्यसपछि nsswitch, प्रति-लिङ्क DNS वा गलत खोज सफिक्स सुधार्नुहोस्।
तपाईंको ल्यापटप VPN मा छ, dig service.internal.example ले 10.x ठेगानासँग जवाफ दिन्छ, र curl अझै Could not resolve host सँग बाहिर निस्कन्छ। सुरुङ समस्या होइन: यसले dig को प्रश्न बिना गुनासो पुर्यायो। फरक यो हो कि प्रश्न कसले सोध्छ। dig ले तपाईंले नाम दिनुभएको एक सर्भरमा एक प्रश्न पठाउँछ, जबकि curl अपरेटिङ सिस्टमको खोज शृंखलाबाट जान्छ, र त्यो शृंखलाका कुन सर्भरलाई सोधिने भन्ने आफ्नै नियमहरू छन्।
एउटै नामका लागि दुई खोज
dig आफ्नै stub resolver हो। यसले /etc/resolv.conf पढ्छ, नेमसर्भर छान्छ, एक A वा AAAA प्रश्न पठाउँछ र जवाफ छाप्छ। यसले nsswitch पूर्ण रूपमा छोड्छ र त्यो फाइलबाहिर systemd-resolved वा NetworkManager ले राख्ने प्रति-लिङ्क अवस्थाबारे केही जान्दैन, त्यसैले dig को जवाफ सही हुन सक्छ र तैपनि तपाईंको अनुप्रयोगले के देख्नेछ भन्नेबारे केही बताउन सक्दैन।
अनुप्रयोगहरूले getaddrinfo कल गर्छन्, र getaddrinfo लामो शृंखलाबाट जान्छ: nsswitch का मोड्युलको क्रम, त्यसपछि नाम सम्हाल्ने मोड्युल, र अन्तमा हालको लिङ्क कन्फिगरेसनबाट बनेको resolver। systemd मेसिनमा प्रश्न 127.0.0.53 मा जान्छ र systemd-resolved ले tun इन्टरफेसमा जोडिएको राउटिङ डोमेनका आधारमा प्रत्येक लिङ्कका लागि माथिल्लो सर्भर छान्छ।
दुई कमाण्डले यी तहहरूलाई अनुमान नगरी अलग गर्छन्:
getent ahosts service.internal.example
resolvectl query service.internal.examplegetent ले curl ले प्रयोग गर्ने उही बाटो प्रयोग गर्छ, त्यसैले चलिरहेको dig को छेउमा getent को असफलताले त्रुटि प्याकेट राउटिङमा होइन, खोज नीतिमा देखाउँछ। resolvectl query ले जवाफ दिने इन्टरफेस र माथिल्लो सर्भर पनि छाप्छ, जसले सुरुङको लिङ्क जित्यो कि भौतिक लिङ्क देखाउँछ।
अनुप्रयोगले वास्तवमै प्रयोग गर्ने resolver पढ्नुहोस्
/etc/resolv.conf अधिकांश डेस्कटपमा उत्पन्न हुन्छ, र VPN क्लाइन्टसँग यसलाई सम्हाल्ने तीन तरिका छन्: नेमसर्भर अगाडि थप्ने, फाइलमाथि लेख्ने, वा आफ्ना सर्भरहरू NetworkManager लाई दिएर डेमनलाई पुनः लेख्न दिने। तेस्रो ढाँचाले मात्र प्रति-लिङ्क DNS जोगाउँछ, किनभने सर्भरहरू एक विश्वव्यापी सूचीमा समतल हुनुको सट्टा इन्टरफेसमा जोडिएर रहन्छन्।
NetworkManager प्रणालीमा नतिजा /etc/NetworkManager/NetworkManager.conf मा रहेको backend मा निर्भर हुन्छ:
[main]
dns=systemd-resolveddns=default सँग क्लाइन्टका सर्भरहरू जित्ने क्रममै resolv.conf मा मिसिन्छन्, र निजी प्रश्न अझै सार्वजनिक resolver मा जान सक्छ। लिङ्क बुझ्ने backend सँग, systemd-resolved वा dnsmasq, सुरुङका सर्भरहरू सुरुङमै सीमित रहन्छन् र त्यहाँ उसको राउटिङ डोमेनसँग मिल्ने नामहरू मात्र जान्छन्। यही सीमाले व्यवहारमा split DNS को अर्थ राख्छ, र क्लाइन्टले यसको समर्थन गरेको दाबी गर्दा प्रायः यही भाग हराइरहेको हुन्छ।
केही बदल्नुअघि अवस्था पढ्नुहोस्:
resolvectl status
resolvectl dns tun0तपाईं tun इन्टरफेस DNS सर्भर र निजी सफिक्सका लागि राउटिङ डोमेनसहित सूचीबद्ध देख्न चाहनुहुन्छ, जो ~internal.example का रूपमा देखियोस्। लिङ्कमा कुनै सर्भर नहुनु भनेको क्लाइन्टले केही पठाएन। डोमेन नभएको सर्भर भनेको प्रश्नहरू या त सबै त्यहाँ जान्छन् या कुनै पनि जाँदैन, क्लाइन्टअनुसार, र यीमध्ये कुनै पनि split DNS होइन।
जहाँ nsswitch ले खोज चाँडै अन्त्य गर्छ
डेस्कटपको सामान्य लाइन यस्तो देखिन्छ:
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnamemdns4_minimal ले मल्टिकास्ट DNS सम्हाल्छ र .local मा अन्त्य हुने हरेक नाममा दाबी गर्छ। api.infra.svc.cluster.local जस्ता Kubernetes सेवा पनि .local मा अन्त्य हुन्छ। mDNS मोड्युलले NOTFOUND जनाउँदा, कार्य [NOTFOUND=return] ले dns मोड्युलतर्फ जानुको सट्टा सम्पूर्ण खोज अन्त्य गर्छ, त्यसैले नाम कहिल्यै VPN resolver मा पठाइँदैन। dig ले फाइल पूर्ण रूपमा छल्छ, र त्यसैले दुई उपकरण एकमत हुँदैनन्।
यो यस समस्याको सबैभन्दा तीखो विरोधाभास हो, र यो तपाईंको VPN भन्दा पुरानो कन्फिगरेसन फाइलको एक शब्दमा टिकेको छ। कार्य [NOTFOUND=continue] मा बदल्दा प्रिन्टर र स्थानीय उपकरणका लागि mDNS रहन्छ र DNS ले नाम देख्न सक्छ। लाइनलाई hosts: files dns ले बदल्नु पनि काम गर्छ र बढी कच्चा छ: यसले तपाईंले वास्तवमै प्रयोग गर्ने प्रिन्टरका लागि .local हल हुन छोड्छ।
ठ्याक्कै एउटै नेटवर्कमा बस्ने नामहरू
निजी जोनहरू ठ्याक्कै एउटै ठाउँमा अधिकारिक हुन्छन्। ip-10-0-4-31.eu-west-1.compute.internal जस्तो AWS नाम त्यही क्षेत्रको VPC resolver मार्फत हल हुन्छ, र तपाईंको VPN एन्डपोइन्ट स्रोत भएकै क्षेत्रमा रहेसम्म मात्र। फ्र्याङ्कफर्टको एन्डपोइन्टमा जोडिनुहोस्, आयरल्यान्डको compute.internal नाम सोध्नुहोस्, र कुनै स्थानीय सेटिङले मद्दत गर्दैन: रेकर्ड राख्ने जोन त्यहाँबाट पुग्न नसकिने ठाउँमा छ।
खोज डोमेनहरूले उल्टो तस्बिर बनाउँछन्। खाली service resolver ले लागू मान्ने सफिक्सले पूरा हुन्छ, र VPN लिङ्क हुँदा स्थानीय डोमेनले कर्पोरेट डोमेनलाई हराउन सक्छ। अनुमान हटाउन अन्तमा बिन्दु राखेर सोध्नुहोस्, getent ahosts service.internal.example., र यदि त्यो चल्यो र छोटो नाम असफल भयो भने, सुधार सुरुङमा रहेको खोज डोमेन हो, सर्भरको ठेगाना होइन।
व्यवस्थित क्लाइन्टहरूले प्रणाली resolver माथि तेस्रो तह थप्छन्। Windows VPN प्रोफाइलले आफ्नै नाम-हल नीति, प्रति-एप नियम र NRPT तालिका बोक्न सक्छ जो सुरुङ बन्द हुँदा पनि लागू हुन्छ। आफ्नै DNS क्यास भएका अनुप्रयोगहरू, जो .NET र Java रनटाइममा सामान्य छन्, शृंखला सुधारिएपछि पनि पुरानो असफलता लामो समय राख्छन्। Apple क्लाइन्टहरूले DNS सेटिङमा मिल्ने डोमेनमार्फत split DNS सेट गर्छन्, resolv.conf मार्फत होइन, र Chromium वा Firefox सुरक्षित DNS मोडमा सार्वजनिक नामका लागि प्रणाली resolver छल्न सक्छन्। VPN नाम-हलबारे Microsoft को सन्दर्भ ले त्यो नीति-तहको Windows पक्ष वर्णन गर्छ।
कुन तह सुधार्ने निर्णय गर्नुहोस्
सुधारहरू क्रममा जाँच्नुको सट्टा लक्षणबाट तहतर्फ जानुहोस्:
| Symptom | What it means | Check first |
|---|---|---|
| dig answers, getent fails | lookup chain, not the packet path | nsswitch line and resolvectl status |
| Timeout rather than NXDOMAIN | private resolver unreachable through the tunnel | resolvectl dns tun0, route to that address |
| NXDOMAIN | an authority answered and does not know the name | zone owner, endpoint region |
| FQDN works, short name fails | search suffix mismatch | resolvectl domain on the tun link |
| getent works, app fails | app cache or its own resolver | restart the app, check secure DNS |
दुई लाइनले धेरै भार बोक्छन्। टाइमआउट पहुँचको समस्या हो: निजी resolver सुरुङबाट जवाफ दिँदैन, त्यसैले उसको ठेगानासम्मको बाटो र लिङ्कको DNS सर्भर तपाईंले सोचेको हो कि होइन जाँच्नुहोस्। NXDOMAIN अधिकारको समस्या हो: कुनैले जवाफ दियो र त्यसले नाम जान्दैन, जसले जोन, क्षेत्र वा यस्तो resolver तर्फ संकेत गर्छ जसले यो प्रश्न कहिल्यै पाउनु हुँदैन थियो।
अन्तिम लाइन त्यो हो जो मानिसहरूले छोड्छन् किनभने दुवै आधा सफलता जस्तो देखिन्छ। FQDN भन्दा फरक हल हुने छोटो नाम सफिक्सको असङ्गति हो, र सुरुङ फेरि जोड्दा क्लाइन्टले कुन सफिक्स पठाउँछ भन्ने बदलिँदैन।
कन्फिगरेसन फाइल बदल्नुअघि अवस्था रेकर्ड गर्नुहोस्, ताकि परिवर्तनले केही गर्यो कि भन्न सकियोस्:
resolvectl status > before.txt
getent ahosts service.internal.example >> before.txtजाँचहरू यही क्रममा चलाउनुहोस् र पहिलो असफलतामा रोकिनुहोस्। getent र resolvectl query मिल्नुपर्छ; यदि getent असफल भयो र dig जवाफ दिइरहेको छ भने, खोज शृंखलामै रहनुहोस् र राउटिङलाई नछुनुहोस्। resolvectl status ले tun इन्टरफेसमा DNS सर्भर र राउटिङ डोमेन देखाउनुपर्छ। nsswitch ले परीक्षण गरिएको सफिक्सका लागि NOTFOUND मा चाँडै फर्कनु हुँदैन। नाम तपाईंको एन्डपोइन्ट जोडिएको नेटवर्कमा अधिकारिक हुनुपर्छ, अन्तमा बिन्दु राखेर परीक्षण गरिएको। अनुप्रयोगले आफ्नै क्यास वा सुरक्षित DNS को ओभरराइड राख्नु हुँदैन।
पहिलो असफल तह मात्र सुधार्नुहोस्, त्यसपछि उही कमाण्ड फेरि चलाउनुहोस्। एकैचोटि दुई परिवर्तनले कुन महत्त्वपूर्ण थियो भन्नबाट रोक्छ, र अर्को खराबीले जाँच शून्यबाट सुरु गर्छ।