VPN का DNS बनाम ब्राउज़र का DoH: लीक टेस्ट आपको क्या नहीं बता सकता
लीक टेस्ट का पता केवल यह दिखाता है कि किस रिज़ॉल्वर ने जवाब दिया। एन्क्रिप्टेड क्वेरी, विभाजित DNS और ब्राउज़र नीति तय करते हैं कि निजी नाम अब भी हल होते हैं या नहीं।
लीक टेस्ट पेज कहता है कि आपका DNS ठीक है, ब्राउज़र का बैज कहता है कि यह सुरक्षित है, और आंतरिक विकी फिर भी लोड नहीं होता। तीनों एक साथ सच हो सकते हैं, क्योंकि रिज़ॉल्वर का पता वह नीति नहीं है जिसने उसे चुना और न ही वह रास्ता जिससे क्वेरी गुज़री। लोग जिसे DNS लीक कहते हैं वह असल में एक सवाल है: नाम किस रिज़ॉल्वर को मिला, और क्या वह चुनाव जानबूझकर था? इसे सुलझाने के लिए तीन जाँचें चाहिए, और केवल अंतिम में ही एक सेटिंग बदलनी होती है।
पहला मिथक: बैज आपके रिज़ॉल्वर का नाम बताता है
लीक टेस्ट एक परीक्षण नाम हल करता है और उस पते की रिपोर्ट करता है जिसने जवाब दिया। यह उस नीति की रिपोर्ट नहीं करता जिसने वह रिज़ॉल्वर चुना, और जब क्वेरी DNS over HTTPS में लिपटी हो, तो रास्ते का कोई बीच का बॉक्स नाम देख ही नहीं सकता। दो बिल्कुल अलग मशीनें वही भरोसा देने वाला बैज पैदा करती हैं: एक जहाँ VPN ने 10.8.0.1 भेजा और ब्राउज़र उसे इस्तेमाल करता है, और दूसरी जहाँ ब्राउज़र ने सिस्टम सूची अनदेखी की और नाम टनल से होते हुए अपने एन्क्रिप्टेड प्रदाता को भेज दिया।
यह अंतर उस पल मायने रखता है जब कोई निजी नाम विफल होता है। पहली व्यवस्था में VPN रिज़ॉल्वर कॉर्पोरेट ज़ोन के लिए जवाब देता है; दूसरी में ब्राउज़र ने उससे कभी पूछा ही नहीं, इसलिए छोटा होस्टनेम हल नहीं होता और विफलता टूटे हुए VPN जैसी दिखती है। यह जाँच कोई दूसरा लीक टेस्ट नहीं है, यह ऐसे नाम की खोज है जिसे केवल एक रिज़ॉल्वर जानता है।
दूसरा मिथक: ब्राउज़र टनल छोड़ देता है
DNS एक पता चुनता है, राउटिंग कनेक्शन ले जाती है, और ये दो अलग परतें हैं। किसी सार्वजनिक DoH प्रदाता को भेजी गई क्वेरी अब भी रूट हो सकने वाले पते के लिए TCP पोर्ट 443 ही है। अगर आपकी रूट तालिका डिफ़ॉल्ट मार्ग को टनल में भेजती है, तो वह क्वेरी भी टनल से होकर जाती है। रिज़ॉल्वर का ब्रांड रास्ता तय नहीं करता।
ब्राउज़र DoH जो बदलता है वह नामों का प्राप्तकर्ता है। यह सच्चा गोपनीयता निर्णय और सच्चा नीति निर्णय है, लेकिन यह राउटिंग बायपास नहीं है। अगर आपकी शर्त यह है कि नाम VPN ऑपरेटर के पास ही रहें, तो किसी और को भेजी एन्क्रिप्टेड क्वेरी उस शर्त को पूरा नहीं करती, जबकि वह वास्तविक कनेक्शन के लिए अब भी टनल इस्तेमाल करती है।
तीसरा मिथक: हर VPN हर ब्राउज़र पर भारी पड़ता है
ब्राउज़र में सुरक्षित DNS के मोड होते हैं, स्विच नहीं: बंद, फ़ॉलबैक वाला डिफ़ॉल्ट प्रदाता, कस्टम टेम्पलेट, या ऑपरेटिंग सिस्टम या संगठन द्वारा लागू नीति। फ़ॉलबैक वाला मामला ही रुक-रुक कर रिपोर्ट पैदा करता है। जब एन्क्रिप्टेड एंडपॉइंट तक पहुँच न हो, तो ब्राउज़र सिस्टम रिज़ॉल्वर पर लौट सकता है, इसलिए वही लैपटॉप सोमवार को निजी नाम सही हल करता है और मंगलवार को नहीं।
उसी समय, ज़्यादातर VPN क्लाइंट कनेक्शन आते ही सिस्टम रिज़ॉल्वर सेट करते हैं और कनेक्शन टूटने पर पिछला बहाल करते हैं। कस्टम एन्क्रिप्टेड रिज़ॉल्वर रखने वाला ब्राउज़र उस बहाली को बिल्कुल नहीं देखता। इसीलिए वही प्रोफ़ाइल दो लैपटॉप पर अलग व्यवहार करती है और इसीलिए resolv.conf सही दिखता है जबकि ब्राउज़र अब भी किसी और से पूछ रहा है।
resolvectl status # per-link DNS servers and split-DNS domains
scutil --dns | head -30 # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1 # ask the VPN resolver directlyकनेक्टेड रहते हुए ये चलाएँ, नोट करें कि हर रिज़ॉल्वर किन डोमेन पर दावा करता है, और ब्राउज़र अपने मोड के बारे में जो बताता है उससे तुलना करें। Mozilla का DoH दस्तावेज़ इस बात का उचित वर्णन है कि ब्राउज़र का डिफ़ॉल्ट और फ़ॉलबैक व्यवहार कैसे काम करना चाहिए।
निर्णय के तीन इनपुट हैं, एक नहीं
निजी नाम, ऑपरेटर पर भरोसा और पहुँच-क्षमता सही व्यवस्था तय करते हैं। जो नाम केवल VPN रिज़ॉल्वर जानता है वे विभाजित DNS को बाध्य करते हैं: निजी प्रत्यय भेजे गए रिज़ॉल्वर को जाता है, और बाकी सब सार्वजनिक नामों के लिए आपकी चुनी नीति का पालन करता है। ऑपरेटर पर भरोसा तय करता है कि क्या सार्वजनिक नाम भी उसी रिज़ॉल्वर को जाने चाहिए या अलग सेवा को। पहुँच-क्षमता तय करती है कि आपका चुना एन्क्रिप्टेड रिज़ॉल्वर इस नेटवर्क पर है भी या नहीं।
| Condition | What it forces |
|---|---|
| Internal names must resolve | Split DNS: private suffixes to the VPN resolver, the rest to your chosen default |
| Queries must stay with one operator | Pin both the system resolver and the browser mode, and disable fallback |
| Resolver only reachable through the tunnel | Keep the pushed resolver; do not point DoH at an endpoint your routes exclude |
इनमें से कोई पंक्ति सार्वभौमिक सिफ़ारिश नहीं है। VPN द्वारा संचालित रिज़ॉल्वर अवलोकनों को उसी ऑपरेटर के पास केंद्रित करता है; अलग सेवा पूछे गए नामों का एक और प्राप्तकर्ता जोड़ती है। दोनों में से कोई व्यवस्था अवधारण के बारे में कुछ साबित नहीं करती, जब तक आप नीति न पढ़ें।
हर प्रोफ़ाइल के लिए निर्णय लिखें, क्योंकि ये सेटिंग्स खिसकती रहती हैं। पिछले महीने रिज़ॉल्वर भेजने वाली प्रोफ़ाइल आज कुछ न भेजे, और ब्राउज़र खुशी से ऐसा पुराना कस्टम एंडपॉइंट रखेगा जो अब भी जवाब देता है। नोट में रिज़ॉल्वर का पता, उसके स्वामित्व वाले प्रत्यय और ब्राउज़र का मोड होना चाहिए, सेवा का ब्रांड नहीं।
उस नीति को परखें जिसे आपने कॉन्फ़िगर किया मानते हैं
बैज से नहीं, नाम से परखें। सिस्टम रिज़ॉल्वर से एक सार्वजनिक नाम और एक निजी नाम हल करें, फिर ब्राउज़र के भीतर उसकी अपनी सुरक्षित DNS सेटिंग के साथ उस मोड में दोहराएँ जिसे आप इस्तेमाल करना चाहते हैं। अगर निजी नाम केवल ब्राउज़र में विफल होता है, तो आपने एक भी VPN सेटिंग बदले बिना प्राप्तकर्ता की असंगति खोज ली है।
फिर दोबारा कनेक्ट करें और बहाली जाँचें, क्योंकि हैंडऑफ़ बग वहीं रहते हैं: डिस्कनेक्ट करें, पुष्टि करें कि पिछला रिज़ॉल्वर लौट आया, फिर कनेक्ट करें, पुष्टि करें कि भेजा गया रिज़ॉल्वर लौट आया। अंत में, अगर आपके पास प्रबंधित नीति वाला ब्राउज़र हो तो उसे परखें, क्योंकि वह मोड आपके बदलाव को पूरी तरह अस्वीकार कर सकता है और चुपचाप पिछला रिज़ॉल्वर रख सकता है।
नेमस्पेस के सवाल से शुरू करें और आप इनमें से ज़्यादातर बच जाएँगे। अगर मशीन को आंतरिक नामों तक पहुँचना है, तो ब्राउज़र का एन्क्रिप्टेड रिज़ॉल्वर केवल सार्वजनिक आधे हिस्से का निर्णय है, और निजी आधा VPN जो भी भेजे उसी के पास रहता है।