तपाईंको ल्यापटपले intranet.corp लाई टनेलबाट समाधान गर्छ जबकि gitlab.com सेवा प्रदायकको रिजोल्भरतिर जान्छ, र यो नै डिजाइन अनुसार काम गर्ने व्यवस्था हो। दुई अलग निर्णयले यो बनाए: नाम मिल्ने नियमले रिजोल्भर छान्यो, र रुटले उत्तर फर्काइ ल्यायो। जुनसुकै एउटा तोड्नुहोस् र ब्राउजरले बाहिरबाट एउटै देखिने असफलता देखाउँछ। विभाजित DNS का अधिकांश प्रतिवेदन दोस्रो असफलताको वर्णन गर्दै पहिलोको प्रमाण उद्धृत गर्छन्।

दुई आधा भाग फरक ठाउँमा बस्छन् र सामान्यतया फरक मानिसले सम्पादन गर्छन्। एउटा VPN प्रोफाइलमा जोडिएको DNS नीति हो, अर्को टनेलले राख्ने वा रोक्ने रुट हो। कुन आधा वास्तवमा सर्यो भनेर कसैले निर्धारण नगरे डिबगिङ रोकिन्छ।

एउटै अनुरोधमा लुकेका दुई निर्णय

नामको आधा नीति वस्तु हो, रुट होइन। Windows मा यो VPN प्रोफाइलमा नाम-समाधान नीति हो; Apple प्लेटफर्ममा DNS सेटिङ्स वस्तुमा मिल्ने डोमेनको समूह; Linux मा रुटिङ डोमेन, विभाजित रिजोल्भर लाइन वा नाम सेवा स्विचको क्रम। बाटोको आधा सामान्य रुटिङ हो, टनेल वा हातले राखिएको, र होस्टनाम के हो भन्ने यसलाई थाहा छैन। प्रत्यय स्वीकार गर्ने प्रोफाइलले को उत्तर दिने मात्र निर्णय गर्छ; यसले उत्तरलाई कहिल्यै पुग्न सकिने बनाउँदैन।

छिटो लक्षण परीक्षणले तिनलाई छुट्याउँछ: नामको ठाउँमा ठेगाना राख्नुहोस्। ठेगाना चल्यो भने बाटो ठीक छ र नियम गलत छ। ठेगाना पनि असफल भयो भने नियम ठीक र बाटो हराएको हुन सक्छ।

प्रत्येक प्लेटफर्मले एउटै नाम नियम कसरी व्यक्त गर्छ

उद्देश्य एउटै छ र क्षेत्रका नाम होइनन्। एउटा क्लाइन्टबाट अर्कोमा प्रतिलिपि गरिएको उदाहरण सफासँग पार्स हुन्छ र कहिल्यै मिल्दैन। तीन रूप यस्तो देखिन्छ:

PlatformWhere the rule livesWhat usually breaks
Windowsname-resolution policy on the VPN profileprecedence against the interface suffix list
Apple platformsmatch domains on the DNS settings objectdomains attached to the wrong extension
Linuxrouting domain, split resolver, nsswitch orderthe 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.10

Windows क्लाइन्टले ती दुई प्रश्न फरक cmdlet सँग सोध्छ। दोस्रोले प्रणालीले वास्तवमा प्रयोग गर्ने इन्टरफेस जनाउँछ:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

खोजले ठेगाना फर्कायो र बाटो जाँचले भौतिक इन्टरफेस भन्यो भने नाम नियम चल्यो र रुट चलेन। छोटो नाम असफल हुँदा पूर्ण नाम समाधान हुन्छ भने प्रत्यय सूची गलत छ, रिजोल्भर होइन।

तुलना सामान्यतया कहाँ गलत हुन्छ

पहिलो गल्ती असम्बन्धित सार्वजनिक रिजोल्भरलाई निजी नामबारे सोध्नु र अस्वीकारलाई VPN बारे प्रमाणका रूपमा पढ्नु हो। दोस्रो चल्ने सार्वजनिक खोजले टनेलको रिजोल्भर बाटो प्रमाणित गर्छ भनी मान्नु हो। तेस्रो विभाजित टनेलिङ र विभाजित DNS लाई एउटै डिजाइन निर्णय मान्नु हो, जबकि तैनाथी एउटामा सही र अर्कोमा बिग्रिएको हुन सक्छ। प्रत्येक गल्तीले आरोप लगाइएको भाग कहिल्यै अभ्यास नगरेको परीक्षणबाट आत्मविश्वासी निष्कर्ष दिन्छ।

आफ्नै सुरक्षित DNS भएको ब्राउजरले पनि प्रणाली नियम बाइपास गर्न सक्छ, त्यसैले एउटा ब्राउजर असफल हुँदा अर्को सफल हुनु विरोधाभास होइन। उत्तर दिने रिजोल्भरको तुलना गर्नुहोस्, गुनासो गर्ने ब्राउजरको होइन।

दुई आधा भाग देखिएपछि बाँकी प्रश्न प्राविधिक होइन, नीतिको हुन्छ: कुन नाम-स्थान संस्थाका हुन्, प्रत्येक उत्तरको मालिक को हो, र तीमध्ये कुनले मेसिन छोड्नुपर्छ। त्यो प्रोफाइलको छेउमा लेख्नुहोस्, किनकि नियम छुने अर्को व्यक्तिलाई त्यसको आवश्यकता पर्नेछ।

सम्बन्धित लेखहरू