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 चे ओव्हरराइड ठेवू नये।
फक्त पहिला अयशस्वी थर दुरुस्त करा, नंतर तोच कमांड पुन्हा चालवा। एकाच वेळी दोन बदल केल्यास कोणता महत्त्वाचा होता हे सांगता येत नाही, आणि पुढील बिघाड तपासणी शून्यापासून सुरू करतो।