तपाईंको VPN ले DNS इन्क्रिप्ट गर्छ, वा अर्को हप मात्र?

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 होस्टबारेको वाक्यले अझै क्वेरी पढ्न सक्छ भन्छ भने, कागजातले पनि त्यही भन्नुपर्छ, किनकि विपरीत दाबी गर्ने रेखाचित्रमाथि आदेश कहिल्यै नचलाएको मानिसले विश्वास गर्नेछ।