DNS को केवल अपने VPN रिज़ॉल्वर से जाने दें: चरण-दर-चरण मार्गदर्शिका
ब्राउज़र से उत्तर तक एक नाम-खोज का पीछा करें। देखें रिज़ॉल्वर कहाँ चुना जाता है, फ़ायरवॉल कहाँ उसे लागू करता है और पोर्ट 53 का नियम कभी क्या नहीं ढकता।
जिस पल आप नाम टाइप करते हैं, उसी पल से एक नाम-खोज का पीछा करें। ब्राउज़र ऑपरेटिंग सिस्टम से पूछता है, ऑपरेटिंग सिस्टम उस रिज़ॉल्वर से पूछता है जिसे उसकी नीति चुनती है, और क्वेरी किसी इंटरफ़ेस से किसी ट्रांसपोर्ट के साथ डिवाइस से बाहर जाती है। आपका VPN डिज़ाइन कहता है कि उत्तर किसी विशेष रिज़ॉल्वर से किसी विशेष पथ से आना चाहिए। इन दो कथनों के बीच का अंतर ही वह है जिसे आप कॉन्फ़िगर करते हैं और फिर लागू करते हैं।
चरण 1: रिज़ॉल्वर और पथ का नाम दें
फ़ायरवॉल को छूने से पहले तीन बातें लिखें: रिज़ॉल्वर का पता, वह प्रोटोकॉल और पोर्ट जिनकी आप अपेक्षा करते हैं, और वह इंटरफ़ेस जिससे क्वेरी बाहर जानी चाहिए। इस सूची के बिना नियम ट्रैफ़िक के बारे में एक अनुमान है, किसी निर्णय का अमल नहीं। VPN एप्लिकेशन का डेटा ले जा सकता है जबकि DNS अलग व्यवस्था का पालन करता है, और यह अपने आप में गलती नहीं है। यह तब होता है जब किसी ने क्लाइंट को कुछ और नहीं बताया हो।
पथ का स्पष्ट नाम देना डिज़ाइन और दुर्घटना के बीच का अंतर है। यह आपको बाद में परखने के लिए कुछ देता भी है, क्योंकि हर अवलोकन की तुलना लिखित अपेक्षा से की जा सकती है। वह सूची बदलाव टिकट में रखें, किसी के सिर में नहीं।
चरण 2: नीति वहीं रखें जहाँ वह वास्तव में रहती है
रिज़ॉल्वर का चयन क्लाइंट का काम है: ऑपरेटिंग सिस्टम का नेटवर्क कॉन्फ़िगरेशन, VPN क्लाइंट की अपनी सेटिंग्स, या प्रबंधित ब्राउज़र नीति। पहले वहीं रखें, उस तंत्र से जिसे प्लेटफ़ॉर्म समर्थन देता है, क्योंकि फ़ायरवॉल क्लाइंट को ऐसा रिज़ॉल्वर चुनने के लिए मजबूर नहीं कर सकता जिसके बारे में उसे कभी बताया ही न गया हो। स्प्लिट-टनल क्लाइंट पर स्पष्ट कहें कि कौन-से डोमेन आंतरिक रिज़ॉल्वर पर जाते हैं। प्रबंधित फ़्लीट में DoH के लिए ब्राउज़र नीति अक्सर एकमात्र रास्ता होती है, क्योंकि ब्राउज़र सिस्टम सेटिंग से स्वतंत्र रूप से अपना एन्क्रिप्टेड रिज़ॉल्वर चुन सकता है।
इसे छोड़कर सीधे फ़ायरवॉल पर जाएँ और आपको ऐसा नियम मिलेगा जो सही रिज़ॉल्वर की अनुमति देता है, साथ में ऐसा क्लाइंट जो उसका कभी उपयोग नहीं करता। नियम सही दिखता है और रिज़ॉल्वर के लॉग खाली रहते हैं, जो डिबग करने के लिए उलझाने वाली जोड़ी है। पहले चयन कॉन्फ़िगर करें, फिर उसे लागू करें।
चरण 3: पथ को सीमित रूप से लागू करें
अब अनुमत पथ के लिए नेटवर्क अनुमति जोड़ें: रिज़ॉल्वर का पता, प्रोटोकॉल और पोर्ट, और वह इंटरफ़ेस जिससे उसे बाहर जाना चाहिए। सभी आउटबाउंड DNS की अनुमति देने के बजाय नियम को उसी रिज़ॉल्वर तक सीमित रखें। नीचे दिए तीन पथ वे हैं जो आधुनिक क्लाइंट ले सकता है, और पोर्ट 53 का नियम केवल पहले को ढकता है।
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
DoH और DoT को अवरुद्ध करना वैध है; यह मानना कि पोर्ट 53 का नियम उन्हें पहले ही अवरुद्ध कर चुका है, वैध नहीं। DoH वाला ब्राउज़र ऐसे पथ से नाम हल करता है जिसे आपके नियम ने कभी वर्णित नहीं किया, और अपना रिज़ॉल्वर साथ लाने वाला एप्लिकेशन भी वही करता है। हर वह पथ लिखें जिसे आप अनुमति देना चाहते हैं और हर वह जिसे अस्वीकार करना चाहते हैं। जो नियम किसी पथ का नाम नहीं लेता, उसने उसके बारे में निर्णय नहीं लिया।
चरण 4: निजी और सार्वजनिक नामों का पीछा करें
विभाजित DNS जानबूझकर केवल निजी नामस्थान आंतरिक रिज़ॉल्वर पर भेजता है जबकि सार्वजनिक नाम कहीं और जाते हैं, इसलिए डिज़ाइन में एक से अधिक रिज़ॉल्वर होना लीक नहीं है। लीक वह क्वेरी है जिसे आपके रिज़ॉल्वर पर जाना चाहिए था और वह कहीं और पहुँचती है, या कोई अगम्य इच्छित पथ जो क्लाइंट को चुपचाप पीछे हटा देता है। यही दो स्थितियाँ खोजने योग्य हैं। इच्छित नीति के अंतर्गत एक आंतरिक और एक सार्वजनिक नाम का पीछा करें और लिखें कि किस रिज़ॉल्वर ने किसे उत्तर दिया।
आपके रिज़ॉल्वर की रिपोर्ट देने वाली परीक्षण साइट संकेत है, प्रमाण नहीं, क्योंकि वह केवल वे क्वेरी देखती है जो उस तक पहुँचीं। जब यह जानना हो कि क्वेरी ने वास्तव में कौन-सा पथ लिया, तो उसे क्लाइंट की ओर कैप्चर करें और फिर दोनों अवलोकनों की तुलना करें। जब वे मेल नहीं खाते, तो आपने ऐसा पतन पाया है जिसे किसी ने दर्ज नहीं किया।
यदि रिज़ॉल्वर का पता सही है पर पहुँच से बाहर है, तो समस्या नीति में नहीं, रूटिंग या फ़िल्टरिंग में है। क्वेरी को उस पते तक ट्रेस करें और कोई भी रिज़ॉल्वर सेटिंग बदलने से पहले पुष्टि करें कि उत्तर अपेक्षित इंटरफ़ेस पर लौटता है।
चरण 5: वापसी का रास्ता खुला रखें
गेटवे पर DNS पहुँच कड़ी करने से पहले ऐसी रिकवरी विधि की पुष्टि करें जो नाम हल होने पर निर्भर न हो। टूटा रिज़ॉल्वर हर मरम्मत उपकरण तक पहुँच कठिन बनाता है, उन सहित जिनसे आप बदलाव वापस लेंगे। नई नीति सिद्ध होने तक स्थानीय कंसोल या आउट-ऑफ़-बैंड पथ खुला रखें। उसे तभी हटाएँ जब नीति ने एक पुनःकनेक्शन झेल लिया हो।
पुनःकनेक्शन या ब्राउज़र नीति अद्यतन के बाद प्रभावी स्थिति फिर से देखें, क्योंकि दोनों आपका नियम बदले बिना रिज़ॉल्वर बदल सकते हैं। आवश्यकता क्वेरी के लिए ज्ञात प्राप्तकर्ता और संरक्षित पथ है, किसी एक स्क्रीनशॉट पर दिलासा देने वाला रिज़ॉल्वर लेबल नहीं। RFC 8484 DNS over HTTPS विनिर्देश उस एन्क्रिप्टेड पथ का संदर्भ है जिसे आपका पोर्ट नियम नहीं देखता।