निजी DNS नाम VPN क्लाइंट पर क्यों विफल होते हैं और कहाँ जाँचें

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

किसी भी प्रोफ़ाइल को संपादित करने से पहले पुष्टि करें कि क्लाइंट नाम के साथ क्या करता है। Linux में resolvectl query files.corp.example दिखाता है कि किस लिंक और किस रिज़ॉल्वर ने उत्तर बनाया। Windows में Resolve-DnsName files.corp.example वह सर्वर दिखाता है जिसने उत्तर दिया और वह पता जो उसने लौटाया।

कुछ भी बदलने से पहले उत्तर पढ़ें

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

यह तीन भागों में बँटवारा एक घंटे का अनुमान बचाता है। यह यह भी बताता है कि VPN को छूना है या नहीं: जो नाम सही निजी पते पर हल होता है, वह रिज़ॉल्वर का रास्ता पहले ही सिद्ध कर चुका है, इसलिए बाकी काम डेटा के रास्ते पर है।

रिज़ॉल्वर को सुरंग के भीतर से बाँटें

क्लाइंट दो समूहों में बँटते हैं। एक को सर्वर कनेक्शन बनते समय रिज़ॉल्वर दे सकता है; दूसरा वह सेटिंग स्थानीय फ़ाइल में रखता है जिसे कोई गेटवे दूर से बदल नहीं सकता।

OpenVPN पहले समूह में है। सर्वर पर push "dhcp-option DNS 10.8.0.53" और push "dhcp-option DOMAIN corp.example" नियंत्रण चैनल से नीचे जाते हैं, पर केवल तब जब क्लाइंट की कॉन्फ़िगरेशन में pull अब भी सक्रिय हो। हाथ से संपादित क्लाइंट जो pull-filter ignore "dhcp-option" लिए हुए है, उन्हें कभी नहीं देखेगा, और यही एक पंक्ति आश्चर्यजनक रूप से बहुत से ऐसे मामलों की व्याख्या करती है कि «सर्वर इसे धकेलता है पर मेरा लैपटॉप नहीं मानता»।

WireGuard दूसरे समूह में है, क्योंकि प्रोटोकॉल में विकल्पों की कोई बातचीत ही नहीं है। रिज़ॉल्वर और खोज डोमेन क्लाइंट के अपने [Interface] ब्लॉक में DNS = 10.8.0.53, corp.example के रूप में जाते हैं। wg-quick इसे resolvconf या systemd-resolved के ज़रिए लागू करता है, और Windows पर आधिकारिक क्लाइंट NRPT के वे नियम स्थापित करता है जो केवल तभी मौजूद होते हैं जब सुरंग खड़ी हो: Get-DnsClientNrptPolicy उन्हें सूचीबद्ध करता है, जो इसे यह देखने का तेज़ तरीका बनाता है कि क्लाइंट ने आपकी फ़ाइल कभी लागू की या नहीं।

IPsec/IKEv2 बीच में है। strongSwan का attr प्लगइन कुंड से निकाला गया DNS सर्वर लौटा सकता है, और Windows क्लाइंट सामान्यतः इसे स्वीकार करता है, पर जो प्रोफ़ाइल अपना नाम सर्वर जमा देती है वह गेटवे की हर पेशकश पर भारी पड़ती है। Linux क्लाइंट पर बराबर का हाथ का क़दम resolvectl dns wg0 10.8.0.53 और फिर resolvectl domain wg0 '~corp.example' है; दोनों इंटरफ़ेस के साथ लुप्त हो जाते हैं, जो सुरंग तक सीमित सेटिंग के लिए ठीक वही है जो आप चाहते हैं।

हर प्रश्न निगलने के बजाय प्रत्यय सीमित करें

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

भीतर केवल निजी प्रत्यय भेजें। systemd-resolved में जो डोमेन ~ से शुरू होता है वह केवल रूटिंग के लिए है, इसलिए ~corp.example का अर्थ है कि उस प्रत्यय के अंतर्गत प्रश्न उसी लिंक के सर्वरों को जाते हैं जबकि बाकी सब भौतिक नेटवर्क का उपयोग करते रहते हैं। Windows यही काम नामस्थान तक सीमित NRPT नियमों से करता है, और macOS /etc/resolver/ के अंतर्गत अतिरिक्त रिज़ॉल्वर फ़ाइल से।

मल्टीकास्ट नाम अपने उत्तर के हक़दार हैं। .local नाम रचना से link-local हैं (RFC 6762) और बिंदु-से-बिंदु tun इंटरफ़ेस वह मल्टीकास्ट समूह नहीं ढोता, इसलिए सार्वजनिक रिज़ॉल्वर जोड़ना उन्हें प्रकाशित नहीं करेगा और आंतरिक unicast रिज़ॉल्वर से उनके बारे में पूछने पर NXDOMAIN लौटता है। avahi जैसा परावर्तक परावर्तन मोड में दो खंड जोड़ सकता है, पर यह सर्वर पक्ष का निर्णय है जिसकी माँग कोई क्लाइंट नहीं कर सकता। अगर प्रिंटर या NAS को नाम से पहुँच योग्य होना ही है, तो उसके बजाय अपने ज़ोन में उसे A रिकॉर्ड दें।

सिद्ध करें कि उत्तर वापस आ सकता है

अपहुँच पते की ओर इशारा करता सही उत्तर बिल्कुल रिज़ॉल्वर की समस्या जैसा दिखता है जब तक आप मार्ग न जाँचें। कर्नेल से पूछें कि उत्तर कहाँ जाएगा: ip route get 10.20.5.20 इंटरफ़ेस और अधिक उपयोगी रूप से वह स्रोत पता बताता है जो वह प्रयोग करेगा।

स्वयं रिज़ॉल्वर के पते पर नज़र रखें। जिस क्लाइंट के पास DNS = 10.8.0.53 के साथ AllowedIPs = 10.20.0.0/16 है, वह अपने प्रश्न भौतिक NIC से बाहर भेजता है, जहाँ वे चुपचाप मर जाते हैं, क्योंकि रिज़ॉल्वर ऐसे किसी उपसर्ग के भीतर नहीं है जिसका सुरंग दावा करती है। यही असंगति इस पूरे क्षेत्र में सबसे आम एक-कारण विफलता है, और यह तब तक अदृश्य रहती है जब तक आप DNS सेटिंग की अनुमत उपसर्गों से पंक्ति दर पंक्ति तुलना न करें।

अतिव्यापी श्रेणियाँ उलटी विफलता पैदा करती हैं। उत्तर सही है, मार्ग मौजूद है, और वह ग़लत मेज़बान की ओर इशारा करता है, क्योंकि घर पर 192.168.0.0/24 उसी श्रेणी के लिए सुरंग के मार्ग से अधिक विशिष्ट है। एक ओर को फिर से क्रमांकित करें या संकरा मार्ग धकेलें, फिर सेवा मेज़बान का फ़ायरवॉल और वापसी मार्ग पुष्ट करें; strongSwan की अग्रेषण पर टिप्पणियाँ उस मार्ग के sysctl पक्ष को समेटती हैं।

प्रमाणपत्र एक अलग पहचान जाँच है जिसका दोष लोग DNS पर डालते हैं। अगर ब्राउज़र हल होने की त्रुटि के बजाय नाम की असंगति बताता है, तो खोज पहले ही काम कर चुकी है और प्रमाणपत्र में SAN ही वह चीज़ है जिसे ठीक करना है। HTTPS को नाम पर जाँचें, कभी नंगे IP पर नहीं।

गेटवे से नहीं, क्लाइंट से दोबारा जाँचें

उसी ऐप्लिकेशन के भीतर जाँचें जिसकी उपयोगकर्ता शिकायत करता है, क्योंकि कमांड लाइन से खोज यह सिद्ध नहीं करती कि ब्राउज़र वही रास्ता लेता है। Chrome का सुरक्षित DNS और Firefox का network.trr.mode सिस्टम रिज़ॉल्वर को पूरी तरह बायपास कर सकते हैं, और जब ऐसा करते हैं तो निजी नाम या तो विफल होता है या किसी सार्वजनिक रिज़ॉल्वर तक रिस जाता है। resolvectl query की हाथ से चलाए गए dig @10.8.0.53 files.corp.example से तुलना बताती है कि दोनों में से क्या हुआ।

फिर इसे ठीक घोषित करने से पहले कनेक्शन काटें और दोबारा जोड़ें। इंटरफ़ेस पर हाथ से लगाई गई सेटिंग उसी इंटरफ़ेस के साथ लुप्त हो जाती हैं, और वह प्रोफ़ाइल जो केवल भूली हुई स्थानीय तब्दीली के कारण सही दिखती थी, अगली बार चलने पर विफल होगी।

अगली मशीन के लिए छोटी सूची: नाम सुरंग के रिज़ॉल्वर से हल होता है, प्रत्यय सीमित है न कि वैश्विक, रिज़ॉल्वर का पता अनुमत उपसर्गों के भीतर है, उत्तर का मेज़बान सेवा के पोर्ट पर उत्तर देता है, और प्रमाणपत्र उस नाम को ढकता है जो उपयोगकर्ता ने लिखा।