VPN सर्वर पर एन्क्रिप्टेड DNS चालू करने को अक्सर लीक बंद करना कहा जाता है, और वह वर्णन छिपाता है कि कौन-सा कनेक्शन बदला। क्लाइंट से रिज़ॉल्वर तक का हॉप और रिज़ॉल्वर से अपस्ट्रीम तक का हॉप अलग-अलग मालिकों वाले अलग कनेक्शन हैं। एक को एन्क्रिप्ट करने से दूसरा ठीक वैसा ही रहता है।

कॉन्फ़िगरेशन फ़ाइल को छूने से पहले हर चरण में लिखें कि क्वेरी किसे मिलती है।

सेटिंग्स पेज पर दो व्यवस्थाएँ एक जैसी दिखती हैं

पहली व्यवस्था में डिवाइस खुद DNS over TLS चलाता है, और टनल सिर्फ़ उस कनेक्शन को आपके चुने हुए रिज़ॉल्वर तक ले जाती है। TLS सत्र रिज़ॉल्वर पर समाप्त होता है, यानी रिज़ॉल्वर क्वेरी देखता है और VPN एग्रेस ऐसा साइफ़रटेक्स्ट देखता है जिसे वह पढ़ नहीं सकता। दूसरी व्यवस्था में डिवाइस सामान्य DNS को टनल से VPN होस्ट पर एक फ़ॉरवर्डर तक भेजता है, और वह फ़ॉरवर्डर अपस्ट्रीम रिज़ॉल्वर के साथ अपना एन्क्रिप्टेड कनेक्शन खोलता है। फ़ीचर सूची में दोनों "VPN के साथ एन्क्रिप्टेड DNS" जैसे दिखते हैं, और पढ़ने योग्य क्वेरी को अलग-अलग इमारतों में रखते हैं।

अंतर मापने योग्य है, दार्शनिक नहीं। क्लाइंट पर या सर्वर पर TLS सत्र खोजें, और आपको पता चल जाएगा कि आपके पास वास्तव में कौन-सी व्यवस्था है।

बदलने से पहले रिज़ॉल्वर श्रृंखला का नक्शा बनाएँ

रास्ते के रिज़ॉल्वर गिनें और हर एक की भूमिका का नाम बताएँ। फ़ॉरवर्डिंग घटक अनुरोध किसी दूसरे रिज़ॉल्वर को सौंपता है, जबकि पुनरावर्ती रिज़ॉल्वर जवाब खोजने का काम करता है और अधिकृत सर्वरों से सीधे बात कर सकता है। ये भूमिकाएँ ठीक इसी कारण अलग-अलग परिभाषित हैं, और RFC 9076 में रिज़ॉल्वर परिभाषाएँ पढ़ने योग्य हैं इससे पहले कि आप मान लें कि एक ही अपस्ट्रीम गंतव्य मौजूद है। जो होस्ट अपना पुनरावर्ती रिज़ॉल्वर चलाता है, उसके पास एन्क्रिप्ट करने के लिए कोई एक "अपस्ट्रीम" नहीं है, जो पूरी योजना को अमान्य कर देता है।

फिर पूछें कि क्लाइंट को कौन-सा घटक इस्तेमाल करने के लिए कॉन्फ़िगर किया गया है। VPN प्रोफ़ाइल द्वारा भेजा गया DNS पता बताता है कि क्वेरियाँ कहाँ जाती हैं, यह नहीं कि कौन-सी प्रक्रिया उनका जवाब देती है।

विफलता का व्यवहार भी देखें। अगर एन्क्रिप्टेड अपस्ट्रीम अगम्य हो जाए, तो फ़ॉरवर्डर बंद होकर विफल होता है, सादे टेक्स्ट पर लौटता है, या किसी दूसरे रिज़ॉल्वर पर लौटता है? यह निर्णय रिकॉर्ड में होना चाहिए, क्योंकि यह उस पल गोपनीयता की गारंटी बदल देता है जब टनल सबसे कम स्वस्थ है।

जाँचें कि कौन-सा हॉप एन्क्रिप्टेड है

क्लाइंट से शुरू करें और पुष्टि करें कि उसके पास पोर्ट 853 तक TLS सत्र है या नहीं। पोर्ट 53 से सही ढंग से हल होने वाली क्वेरी एन्क्रिप्शन के बारे में कुछ साबित नहीं करती।

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

फिर VPN होस्ट पर जाएँ और वह बाहर जाने वाला एन्क्रिप्टेड कनेक्शन खोजें जो फ़ॉरवर्डर ने खोला। सॉकेट तालिका बताती है कि अपस्ट्रीम TLS सत्र मौजूद है या नहीं, और कौन-सी प्रक्रिया उसका मालिक है:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

अगर क्लाइंट TLS सत्र दिखाता है और सर्वर कुछ नहीं, तो आप पहली व्यवस्था में हैं और सर्वर IP स्तर पर भेजी जाने वाली क्वेरियाँ पढ़ नहीं सकता। अगर सर्वर TLS सत्र दिखाता है और क्लाइंट टनल के अंदर पोर्ट 53 पर सामान्य ट्रैफ़िक दिखाता है, तो आप दूसरी व्यवस्था में हैं: अगला हॉप सुरक्षित है, पर फ़ॉरवर्डर अब भी हर वह नाम पढ़ता है जो डिवाइस माँगता है। वह दूसरा नतीजा विफलता नहीं है, पर उसे एंड-टू-एंड एन्क्रिप्शन कहना ग़लत है।

मालिक और विफलता का व्यवहार दर्ज करें

स्वामित्व तय करता है कि आप क्या वादा कर सकते हैं। डिवाइस का मालिक क्लाइंट-साइड एन्क्रिप्टेड कनेक्शन नियंत्रित करता है, जबकि VPN प्रशासक उस अगले कनेक्शन को नियंत्रित करता है जो उसका फ़ॉरवर्डर बनाता है। जो दोनों में से किसी को नहीं चलाता, वह सिर्फ़ रास्ते का वर्णन कर सकता है।

कुछ भी चालू करने से पहले आंतरिक नामकरण जाँचें। संगठनात्मक नाम सार्वजनिक रिज़ॉल्वर को भेजना समतुल्य डिज़ाइन नहीं है, और split-horizon ज़ोन जो सिर्फ़ नेटवर्क के अंदर मौजूद है, अपस्ट्रीम में बिलकुल भी हल नहीं होगा। बदलाव के बाद एक आंतरिक और एक सार्वजनिक नाम जाँचें और नतीजा कॉन्फ़िगरेशन बदलाव के साथ रखें। अगर एन्क्रिप्टेड रास्ता आंतरिक होस्ट के रिज़ॉल्यूशन को तोड़ता है, तो उपाय चौड़ी टनल नहीं बल्कि सीमित दायरे का रिज़ॉल्वर नियम है।

हर हॉप के लिए एक वाक्य लिखकर समाप्त करें: किस घटक को क्वेरी मिली, वह हॉप एन्क्रिप्टेड था या नहीं, और नाम कौन पढ़ सकता है। जब VPN होस्ट वाला वाक्य अब भी कहता है कि वह क्वेरियाँ पढ़ सकता है, तो दस्तावेज़ीकरण को यही कहना चाहिए, क्योंकि उलटा दावा करने वाले आरेख पर वह व्यक्ति भरोसा करेगा जिसने कभी ये कमांड चलाए ही नहीं।

संबंधित लेख