हरेक विभाजित DNS अनुरोध एउटै वाक्यबाट सुरु हुन्छ: कम्पनीका नामहरू कम्पनीको DNS मा जान्छन्, बाँकी सबै काम गरिरहन्छ। त्यो वाक्यलाई कन्फिगरेसनमा बदल्नु भनेको प्रत्येक अपरेटिङ सिस्टमका लागि तीन प्रश्नको जवाफ दिनु हो, र जवाफहरू प्रत्येकमा फरक संयन्त्र प्रयोग गर्छन्। Linux ल्यापटपमा चल्ने प्रोफाइलहरू Windows मा प्रायः टनेलसँग कुनै सम्बन्ध नभएका कारणले असफल हुन्छन्। अन्तर प्रायः रुट ठानिएको रिजोल्भर सेटिङ हुन्छ।

पहिले नीतिको नाम दिनुहोस्, त्यसपछि त्यसलाई व्यक्त गर्ने प्लेटफर्म प्रिमिटिभ छान्नुहोस्।

अलमल्याउन सजिलो तीन सेटिङ

खोज प्रत्ययले छोटो नाम विस्तार गर्छ: files टाइप गर्दा रिजोल्भरले प्रत्ययहरू क्रममा प्रयास गर्दा त्यो files.corp.example हुन्छ। रुटिङ डोमेनले नामस्थानभित्रका प्रश्नहरूको जवाफ कुन रिजोल्भरले दिने भनी छान्छ। IP रुटले छानिएको रिजोल्भरलाई मात्र पहुँचयोग्य बनाउँछ। यी तीन फरक तहमा बस्छन्, र एउटालाई अर्कोले बदल्दा सही देखिने तर केही पनि समाधान नगर्ने कन्फिगरेसन बन्छ।

अलमलको मूल्य हुन्छ: खोज प्रत्यय थप्दा हरेक छोटो नाम कामको रिजोल्भरमा जान्छ, अन्यत्रका नामहरू पनि सहित। रुटिङ डोमेन छान्दा असम्बन्धित प्रश्नहरू स्थानीय रिजोल्भरमा रहन्छन् र तैपनि *.corp.example टनेलबाट पठाइन्छ।

Linux: रुट-मात्र डोमेन, खोज प्रत्यय होइन

systemd-resolved मा टिल्डेबाट सुरु हुने डोमेन रुट-मात्र डोमेन हो, जसको अर्थ त्यो नामस्थानका प्रश्नहरू खोज प्रत्यय पनि नबनी जोडिएको रिजोल्भरमा जान्छन्। resolvectl domain tun0 '~corp.example' ले त्यो सेट गर्छ, र resolvectl dns tun0 10.8.0.1 ले सर्भरको नाम दिन्छ। दुवै सेटिङ इन्टरफेसका हुन्, त्यसैले त्यसैसँग हराउँछन्। टिल्डे नै मानिसहरूले छाड्ने भाग हो, र त्यो बिना छोटा नामहरू कामको रिजोल्भरबाट समाधान हुन थाल्छन्।

त्यही डोमेनलाई विश्वव्यापी खोज प्रत्ययका रूपमा पनि नराख्नुहोस्। दुवै सेटिङ अनावश्यक होइनन्; एउटाले रुट गर्छ र अर्कोले तपाईंले टाइप गरेको पुनः लेख्छ।

Windows लाई नामस्थान नीति चाहिन्छ, प्रत्यय होइन

Windows ले विभाजित DNS नीति Name Resolution Policy Table मा राख्छ, एडाप्टरको DNS प्रत्ययमा होइन। नियमले नामस्थानलाई विशेष सर्भरसँग जोड्छ: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1। केवल प्रत्यय सेट गर्दा छोटा नाम कस्तो देखिन्छ त्यो मात्र बदलिन्छ; यसले प्रश्नलाई अर्को सर्भरमा पठाउँदैन।

जडान गरेपछि Get-DnsClientNrptPolicy ले प्रभावकारी नीति जाँच्नुहोस्, किनकि अघिल्लो जडानको नियम टनेलभन्दा लामो समय रहन सक्छ। टनेल झर्दा नियमहरू नामले हटाउनुहोस्, र सफाइले सही प्रविष्टि भेटोस् भनी देखिने नाम स्थिर राख्नुहोस्।

प्रत्येक प्लेटफर्मका लागि एक रिजोल्भर मालिक

डेस्कटप म्यानेजर, OpenVPN अप स्क्रिप्ट र स्थानीय रिजोल्भर डेमन सबैले एउटै कन्फिगरेसन लेख्न प्रयास गर्न सक्छन्। उनीहरू नमिल्दा अन्तिम लेख्ने जित्छ र नतिजा टियरडाउनको क्रममा निर्भर हुन्छ। रिजोल्भर अवस्थाको मालिक एउटा कम्पोनेन्ट छान्नुहोस्, अरूलाई लेख्नुको सट्टा रिपोर्ट गर्न दिनुहोस्, र पुनः जडान परीक्षण गर्नुहोस्: नीतिले नियम दोहोर्याए बिना त्यो सहनुपर्छ। विच्छेद पनि परीक्षण गर्नुहोस्, किनकि बाँकी रहेको अवस्थाले नै अर्को जडानलाई फरक व्यवहार गराउँछ।

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

नतिजा जाँच्नुहोस्, प्रोफाइलको पाठ होइन

टनेलबाट जानुपर्ने एउटा नाम र जानु नहुने एउटा नाम प्रत्येक प्लेटफर्ममा समाधान गर्नुहोस्, र कुन सर्भरले जवाफ दियो प्रमाणित गर्नुहोस्। resolvectl query host.corp.example र Resolve-DnsName host.corp.example दुवैले जवाफ दिएको सर्भर रिपोर्ट गर्छन्। पुनः जडानपछि दोहोर्याउनुहोस्। त्यसपछि प्रोफाइलले धकेल्ने ठेगानामा टनेलको रिजोल्भर पहुँचयोग्य छ भनी प्रमाणित गर्नुहोस्, किनकि पहुँच नहुने सर्भरतर्फ देखाउने सही नीति पनि नीति नै नभएजस्तै असफल हुन्छ।

इच्छित व्यवहार प्रोफाइलका नोटमा लेख्नुहोस्: कुन प्रत्ययले रुट गर्छ, कुन सर्भरले त्यसको जवाफ दिन्छ, र बाँकी सबैलाई के हुन्छ। अब तपाईंले समर्थन गर्ने प्लेटफर्मलाई कन्फिग फाइलभन्दा त्यो वाक्य बढी चाहिन्छ।

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