विभाजित DNS और VPN: डोमेन नियम IP रूट नहीं हैं
विभाजित DNS नाम के अनुसार रिज़ॉल्वर चुनता है, और उत्तर को अभी भी रूट चाहिए। डोमेन नियम और पथ को अलग-अलग जाँचें, उसी प्लेटफ़ॉर्म पर जो आप वास्तव में चलाते हैं।
आपका लैपटॉप intranet.corp को टनल से हल करता है जबकि gitlab.com सेवा प्रदाता के रिज़ॉल्वर की ओर ही जाता रहता है, और यही वह व्यवस्था है जो डिज़ाइन के अनुसार काम करती है। दो अलग निर्णयों ने इसे बनाया: नाम-मिलान नियम ने रिज़ॉल्वर चुना, और रूट ने उत्तर वापस लाया। इनमें से कोई भी तोड़ें और ब्राउज़र वह विफलता दिखाता है जो बाहर से एक जैसी दिखती है। विभाजित DNS की अधिकांश रिपोर्टें दूसरी विफलता का वर्णन करती हैं और साथ में पहली के प्रमाण उद्धृत करती हैं।
दोनों आधे अलग-अलग जगहों पर रहते हैं और आम तौर पर अलग लोग उन्हें संपादित करते हैं। एक VPN प्रोफ़ाइल से जुड़ी DNS नीति है, दूसरा वह रूट है जिसे टनल स्थापित करता है या रोकता है। डिबगिंग रुक जाती है जब कोई तय नहीं करता कि वास्तव में कौन-सा आधा हिला।
एक अनुरोध में छिपे दो निर्णय
नाम वाला आधा नीति ऑब्जेक्ट है, रूट नहीं। Windows पर यह VPN प्रोफ़ाइल पर नाम-समाधान नीति है; Apple प्लेटफ़ॉर्म पर DNS सेटिंग्स ऑब्जेक्ट पर मेल खाने वाले डोमेन का समूह; Linux पर रूटिंग डोमेन, विभाजित रिज़ॉल्वर पंक्ति या नाम सेवा स्विच का क्रम। पथ वाला आधा सामान्य रूटिंग है, जिसे टनल या हाथ से स्थापित किया जाता है, और उसे पता ही नहीं कि होस्टनाम क्या है। जो प्रोफ़ाइल प्रत्यय स्वीकार करता है वह केवल तय करता है कि कौन उत्तर देगा; वह उत्तर को कभी पहुँच-योग्य नहीं बनाता।
एक तेज़ लक्षण परीक्षण उन्हें अलग करता है: नाम के स्थान पर पता रखें। यदि पता काम करता है, तो पथ ठीक है और नियम गलत है। यदि पता भी विफल होता है, तो नियम सही हो सकता है और पथ अनुपस्थित।
प्रत्येक प्लेटफ़ॉर्म एक ही नाम नियम कैसे व्यक्त करता है
मंशा समान है और फ़ील्ड के नाम नहीं। एक क्लाइंट से दूसरे में कॉपी किया गया उदाहरण साफ़ तरीके से पार्स होता है और कभी मेल नहीं खाता। तीन रूप ऐसे दिखते हैं:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
मिलान या रूटिंग डोमेन एक प्रत्यय परीक्षण है, इसलिए intranet.corp git.intranet.corp को कवर करता है और corp.intranet को नहीं, और इसे उलट देना पूरी सेटिंग की सबसे आम गलती है। Windows मैपिंग को प्रोफ़ाइल से जुड़ी नाम-समाधान नीति के रूप में रखता है, इंटरफ़ेस के पास पहले से मौजूद किसी भी प्रत्यय सूची के मुकाबले अपने स्वयं के प्राथमिकता क्रम के साथ। Apple प्लेटफ़ॉर्म मेल खाने वाले डोमेन को नेटवर्क एक्सटेंशन के DNS सेटिंग्स ऑब्जेक्ट से जोड़ते हैं, और सिस्टम उन्हें हर सीमित रिज़ॉल्वर पर लागू करता है। इन रूपों में से कोई भी रूट नहीं है, और कोई भी अगम्य पते को गम्य नहीं बना सकता। Windows नाम-समाधान नीति संदर्भ उस प्लेटफ़ॉर्म के फ़ील्ड नाम और प्राथमिकता नियम सूचीबद्ध करता है, और वे वही नहीं हैं जो Apple या systemd के दस्तावेज़ उपयोग करते हैं।
सही उत्तर को अभी भी पथ चाहिए
रिज़ॉल्वर का उत्तर केवल एक पता है, और एप्लिकेशन को अभी भी वहाँ पहुँचना है। विभाजित-टनल डिज़ाइन अक्सर 10.20.0.0/16 को धकेलता है और डिफ़ॉल्ट रूट रोक लेता है, इसलिए आंतरिक नाम हल होता है और कनेक्शन फिर लटक जाता है। उलटा मामला भी उतना ही आम है: रूट मौजूद है, एक सार्वजनिक रिज़ॉल्वर निजी नाम को NXDOMAIN के साथ उत्तर देता है, और विफलता रूटिंग समस्या के रूप में दर्ज होती है। पहले पथ जाँचने से आप उस नाम के लिए रूट देखते रह जाते हैं जिसे कभी हल होना ही नहीं था।
एक तीसरा द्वार भी है जिसे कोई आधा कवर नहीं करता। गेटवे पर ACL, फ़ायरवॉल नियम या क्लाइंट-पक्ष नीति दोनों निर्णय सही होने के बाद भी कनेक्शन गिरा सकती है। जब नाम हल होता है, रूट मौजूद है और कनेक्शन फिर भी समय समाप्त करता है, तो DNS जाँचना बंद करें।
निश्चित क्रम में नाम और पथ जाँचना
एक क्रम चुनें और उसे पकड़े रहें, वरना आप उस चरण का पीछा करेंगे जो सबसे हाल में विफल हुआ। दस्तावेज़ीकृत पूर्ण आंतरिक नाम हल करें, पुष्टि करें कि उत्तर वह पता है जिसे रूट तालिका वहन कर सकती है, फिर सार्वजनिक नाम के साथ दोहराएँ ताकि सिद्ध हो कि टनल ने सब कुछ नहीं पकड़ा। systemd होस्ट पर क्वेरी और रिज़ॉल्वर का रूटिंग डोमेन एक कमांड की दूरी पर हैं:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows क्लाइंट वही दो प्रश्न अलग cmdlets के साथ पूछता है। दूसरा वह इंटरफ़ेस बताता है जिसे सिस्टम वास्तव में उपयोग करेगा:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10यदि खोज पता लौटाती है और पथ जाँच भौतिक इंटरफ़ेस का नाम लेती है, तो नाम नियम काम कर गया और रूट नहीं। यदि छोटा नाम विफल होता है जबकि पूर्ण नाम हल होता है, तो प्रत्यय सूची गलत है, रिज़ॉल्वर नहीं।
तुलना आमतौर पर कहाँ गलत होती है
पहली गलती असंबंधित सार्वजनिक रिज़ॉल्वर से निजी नाम के बारे में पूछना और इनकार को VPN के बारे में प्रमाण के रूप में पढ़ना है। दूसरी यह मानना है कि काम करने वाली सार्वजनिक खोज टनल का रिज़ॉल्वर पथ सिद्ध करती है। तीसरी यह है कि विभाजित टनलिंग और विभाजित DNS को एक ही डिज़ाइन निर्णय माना जाए, जबकि कोई परिनियोजन एक में सही और दूसरे में टूटा हो सकता है। हर गलती ऐसी परीक्षा से आत्मविश्वासी निष्कर्ष निकालती है जिसने कभी आरोपित भाग का अभ्यास नहीं किया।
अपना सुरक्षित DNS रखने वाला ब्राउज़र भी सिस्टम नियम को बायपास कर सकता है, इसलिए एक ब्राउज़र का विफल होना जबकि दूसरा सफल होना कोई विरोधाभास नहीं है। जिस रिज़ॉल्वर ने उत्तर दिया उसकी तुलना करें, उस ब्राउज़र की नहीं जिसने शिकायत की।
एक बार दोनों आधे दिख जाएँ, तो बचा हुआ प्रश्न नीति का है, तकनीकी नहीं: कौन-से नामस्थान संगठन के हैं, हर उत्तर का स्वामी कौन है, और उनमें से किन्हें मशीन छोड़नी चाहिए। इसे प्रोफ़ाइल के पास लिख लें, क्योंकि नियम को छूने वाले अगले व्यक्ति को इसकी ज़रूरत होगी।