OpenVPN वर विभाजित DNS: प्रत्येक ऑपरेटिंग सिस्टमवर राउटिंग डोमेनने काय करावे

प्रत्येक विभाजित 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 दोन्ही उत्तर देणाऱ्या सर्व्हरचा अहवाल देतात। पुन्हा कनेक्ट केल्यानंतर पुन्हा करा। मग प्रोफाइल पुश करत असलेल्या पत्त्यावर टनेलचा रिझॉल्व्हर पोहोचण्यायोग्य असल्याची खात्री करा, कारण पोहोचता येत नसलेल्या सर्व्हरकडे बोट दाखवणारे बरोबर धोरणही धोरणच नसल्यासारखेच अयशस्वी होते।

इच्छित वर्तन प्रोफाइलच्या नोंदींमध्ये लिहा: कोणता प्रत्यय मार्ग दाखवतो, कोणता सर्व्हर त्याला उत्तर देतो, आणि बाकी सर्वांना काय होते। पुढे तुम्ही समर्थन देणारा प्लॅटफॉर्म कॉन्फिग फाइलपेक्षा ते वाक्य अधिक गरजेचे असेल।