VPN पर आंतरिक नाम विफल, जबकि सार्वजनिक साइटें ठीक खुलती हैं

एक उपयोगकर्ता बताता है कि VPN पर इंट्रानेट होस्टनाम हल नहीं होता। उसी लैपटॉप से दूसरी रिपोर्ट कहती है कि लीक परीक्षण अब भी दिखाता है कि क्वेरी का उत्तर स्थानीय रिज़ॉल्वर दे रहा है। ये एक समस्या जैसी लगती हैं और दो हैं, अलग सबूतों के साथ, और पहली का सामान्य उपचार दूसरी को बिगाड़ देता है। कोई सेटिंग छूने से पहले इन्हें अलग करें।

दो लक्षण जो एक खराबी नहीं हैं

आंतरिक नाम हल न होने का अर्थ है कि प्रश्न कहीं ऐसी जगह गया जहाँ उसका उत्तर नहीं है। सुरंग से बाहर जाती क्वेरी का अर्थ है कि प्रश्न गलत जगह गया, तब भी जब उत्तर उपलब्ध था। ये विपरीत विफलताएँ हैं: एक में उत्तर गायब है, दूसरी में एक अतिरिक्त गंतव्य है।

जाल यह है कि ऑफ़िस रिज़ॉल्वर को हर जगह जोड़ने से पहली ठीक हो जाती है और दूसरी निश्चित हो जाती है। सार्वजनिक रिज़ॉल्वर हर जगह जोड़ने से उल्टा होता है।

दोनों अवलोकन समय-चिह्न के साथ लिखें, फिर नीचे दी गई चार जाँच क्रम से करें।

कौन-सा अडैप्टर रिज़ॉल्वर प्रश्न पाता है

Windows पर DNS क्लाइंट अडैप्टर बाइंडिंग क्रम के अनुसार सर्वर चुनता है, और सुरंग अडैप्टर स्वतः पहला नहीं होता। अडैप्टर की उन्नत सेटिंग खोलें और रिमोट एक्सेस कनेक्शन को भौतिक अडैप्टर से ऊपर ले जाएँ, फिर दोबारा कनेक्ट करें ताकि बदलाव नए सत्र पर लागू हो।

बाइंडिंग क्रम केवल पहला आधा है। क्लाइंट को यह भी जानना है कि कौन-से नाम उस अडैप्टर के हैं, और यह क्रम का नहीं, प्रत्यय का प्रश्न है।

कार्यशील मशीन का ipconfig /all लैपटॉप के साथ रखें, दोनों सुरंग चालू रहते लिए गए। कार्यशील मशीन अपने ऑफ़िस अडैप्टर पर कनेक्शन-विशिष्ट DNS प्रत्यय दिखाएगी, और लैपटॉप सुरंग पर शायद कुछ न दिखाए। यह अंतर ऐसी पूरी श्रेणी की रिपोर्ट समझाता है जिनमें कहा जाता है कि सर्वर वहीं है और नाम फिर भी विफल है, क्योंकि प्रत्यय के बिना छोटा नाम कभी उस ज़ोन तक पूरा नहीं होता जिसे ऑफ़िस रिज़ॉल्वर परोसता है।

छोटे नाम को मार्ग से पहले प्रत्यय चाहिए

बिना योग्यता वाला होस्टनाम टाइप करने पर रिज़ॉल्वर से डोमेन अनुमान लगाने को कहा जाता है। अनुमान कनेक्शन से जुड़ी प्रत्यय सूची से आता है, और यदि वह सूची खाली है तो क्वेरी एक ही लेबल के रूप में जाती है जिससे कोई निजी ज़ोन मेल नहीं खाएगा।

कार्यशील मशीन का प्रत्यय VPN अडैप्टर के IPv4 गुणों में DNS टैब पर कॉपी करें, फिर दोबारा कनेक्ट करें। Linux पर इसका समतुल्य सुरंग लिंक पर खोज डोमेन है, जिसे systemd-resolved वैश्विक रूप से नहीं, प्रति लिंक प्रकट करता है।

दोनों सेटिंग अपने नोट्स में अलग रखें। प्रत्यय बदलता है कि क्या पूछा जाता है; रिज़ॉल्वर पता बदलता है कि किससे पूछा जाता है। एक को ठीक करना जब दूसरा गलत हो, ऐसा परिणाम देता है जो यादृच्छिक लगता है।

रिज़ॉल्वर से सीधे पूछें, फिर नाम से

ऑफ़िस रिज़ॉल्वर से सीधी क्वेरी नाम की समस्या को मार्ग की समस्या से अलग करती है, क्योंकि यह क्लाइंट के रिज़ॉल्वर चयन को पूरी तरह बायपास करती है।

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

पहला कमांड किसी विशिष्ट सर्वर से पूर्ण योग्य नाम पूछता है। यदि वह उत्तर देता है, तो रिज़ॉल्वर और उसका मार्ग ठीक हैं और खराबी चयन या प्रत्यय में है। यदि समय समाप्त होता है, तो पता गलत है या पहुँच से बाहर है और समस्या DNS की नहीं, रूटिंग की है। दूसरा कमांड दिखाता है कि छोटे नाम के साथ क्या होता है, और तीसरा systemd होस्ट पर प्रति-लिंक रिज़ॉल्वर कॉन्फ़िगरेशन छापता है।

वाइल्डकार्ड उत्तरों पर ध्यान दें, जो कुछ नेटवर्क अज्ञात नामों के लिए लौटाते हैं। प्रशंसनीय दिखने वाला उत्तर इस बात का प्रमाण नहीं है कि इच्छित सर्वर ने उत्तर दिया, इसलिए लौटाए गए पते की तुलना उस पते से करें जो आंतरिक सेवा वास्तव में उपयोग करती है। यदि पता किसी पार्किंग पेज या प्रॉक्सी का है, तो रिज़ॉल्वर ने उत्तर दिया पर वह उत्तर कभी आपका था ही नहीं। यह अंतर उस सुरंग का पीछा करने से एक घंटा बचाता है जो शुरू से ही काम कर रही थी।

Linux पर, वह VPN क्लाइंट जो /etc/resolv.conf को फिर से लिखता है, स्थानीय रिज़ॉल्वरों को पूरी तरह बदल देता है। vpnc इसे रोकने के लिए DNSUpdate no प्रकट करता है, और systemd-resolved केवल सूचीबद्ध डोमेन को सुरंग लिंक पर भेज सकता है। दोनों दृष्टिकोण सार्वजनिक नाम स्थानीय रिज़ॉल्वर पर रखते हैं और आंतरिक नाम ऑफ़िस को भेजते हैं।

लीक एक नियम है, चेकबॉक्स नहीं

नाम विभेदन पोर्ट 53 पर UDP का आदान-प्रदान है, इसलिए वह सुरंग जो वेब ट्रैफ़िक ले जाती है पर UDP नहीं, क्वेरी को भौतिक मार्ग पर छोड़ देती है। इसे सिद्ध करने के लिए सार्वजनिक नाम हल होते समय भौतिक NIC पर कैप्चर करें। उस इंटरफ़ेस पर पठनीय रूप में दिखने वाली क्वेरी का अर्थ है कि सुरंग उसे नहीं ले जा रही।

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

यदि क्वेरी उस इंटरफ़ेस पर पठनीय रूप में दिखती है, तो सुरंग उसे नहीं ले जा रही। उपचार वह नियम है जो पोर्ट 53 की अनुमति केवल उस रिज़ॉल्वर को देता है जिसे VPN ने भेजा और अन्य गंतव्यों को छोड़ देता है, साथ में ऐसा क्लाइंट कॉन्फ़िगरेशन जो भेजे गए विकल्प को चुपचाप नहीं हटाता।

यह अंतिम हिस्सा जितना दिखता है उससे अधिक मायने रखता है। OpenVPN को इसके साथ शुरू करें: route-nopull और भेजा गया DNS विकल्प मार्गों के साथ गायब हो जाता है, जब तक पुल फ़िल्टर को उसे रखने के लिए चौड़ा न किया जाए। और जो क्लाइंट इसकी अनदेखी करता है: dhcp-option DNS वह पहले जो था उसी का उपयोग करता रहेगा। सर्वर पक्ष पर कोई भी बदलाव लागू होने के लिए नए सत्र की आवश्यकता रखता है, क्योंकि रिज़ॉल्वर सूची सुरंग उठते समय दी जाती है और पुराना सत्र पुरानी स्थिति दिखाता रहता है।

टिकट बंद करने से पहले लिखें कि आपने वास्तव में कौन-सी विफलता देखी। आंतरिक उत्तर का गायब होना और सुरंग से बचती क्वेरी अलग उपचार माँगते हैं, और पहली को ठीक करने वाला प्रत्यय परिवर्तन दूसरी को चुपचाप बिगाड़ सकता है। अगला व्यक्ति लेबल पर भरोसा करेगा, इसलिए लेबल सटीक रखें।