तपाईंको VPN को DNS ब्याकअप: क्वेरी साँच्चै कहाँ जान्छ

रिजोल्भरको सेटिङ निजी ठेगानाबाट सार्वजनिक ठेगानामा जान्छ, र निष्कर्ष तुरुन्तै आउँछ: टनेल चुहिरहेको छ। कहिलेकाहीँ त्यस्तै हुन्छ। प्रायः ब्याकअप क्वेरी अझै टनेलभित्रै प्रशासकले छानेको रिजोल्भरकहाँ गएको थियो, र यसले यसलाई खराबी नभई नीतिको निर्णय बनाउँछ। यी अवस्थाहरू छुट्याउन एक होइन, तीन तथ्य चाहिन्छ, र तीमध्ये पहिलो यो हो कि जवाफ कसले दियो। क्वेरी कसले पायो, कुन मार्गले लग्यो र कुन नाम सोधियो पत्ता लगाउनुहोस्।

ब्याकअप एक नीति हो, एउटै व्यवहार होइन

हरेक क्लाइन्टले रोजेको रिजोल्भरले जवाफ दिन छोड्दा के गर्ने भनेर निर्णय गर्नुपर्छ। यसले समाधान रोक्न, फेरि प्रयास गर्न, तोकिएको विकल्प प्रयोग गर्न वा यो अपरेटिङ सिस्टममा छोड्न सक्छ, र गोपनीयताको दृष्टिले यी चार फरक उत्पादन हुन्। सेटिङ स्क्रिन पढ्दा कुन व्यवहार तोकिएको छ भन्ने थाहा हुन्छ; कुन भयो भन्ने हुँदैन। एउटै स्विच भएको स्क्रिनले चार सम्भावना वर्णन गर्दैन।

ब्राउजरहरूले आफ्नै तह थप्छन्। सुरक्षित DNS सक्रिय भएको ब्राउजरले नाम आफ्नै छानेको प्रदायकमार्फत समाधान गर्न सक्छ, अपरेटिङ सिस्टमले अन्तै देखाए पनि, जसको अर्थ टनेल क्लाइन्टको नीति तपाईंलाई साँच्चै महत्त्वपूर्ण अनुरोधहरूमा कहिल्यै सोधिन नसक्ने हुन सक्छ। अनुरोध पठाउने एप जाँच्नुहोस्, सिस्टम सेटिङ मात्र होइन।

वैकल्पिक रिजोल्भरको पहिचान पहिलो तथ्य हो जुन प्रमाणित गर्न लायक छ। तपाईंले पहिल्यै विश्वास गर्ने प्रदायकको सार्वजनिक रिजोल्भर तपाईं संयोगवश जुन नेटवर्कमा हुनुहुन्छ त्यसले दिएको ठेगानाभन्दा फरक अवस्था हो। ठेगाना आफैले यी दुईमध्ये कुनलाई हेरिरहनुभएको छ भन्ने विरलै बताउँछ।

बदलेपछि क्वेरी कसले पाउँछ

प्राप्तकर्ता र मार्ग स्वतन्त्र छन्, र तिनको संयोजनले मात्र जोखिम वर्णन गर्छ। टनेलबाट पुगेको सार्वजनिक रिजोल्भरले तपाईंको पहुँच नेटवर्कको ठेगाना कहिल्यै देख्दैन, जबकि त्यही रिजोल्भर सिधै पुग्दा देख्छ। दुवै अवस्थाले जवाफ दिन्छन्, र केवल रिजोल्भरको ठेगाना बताउने चुहावट परीक्षणले दुवैलाई एउटै रूपमा वर्णन गर्नेछ। नतिजा पढ्दा ठेगानासँगै इन्टरफेस पनि सोध्नुहोस्।

भित्री नामहरूले यो भिन्नता ठोस बनाउँछन्। सार्वजनिक रिजोल्भर सामान्यतया split-horizon नामको जवाफ दिन सक्दैन, त्यसैले क्वेरी असफल हुन्छ जबकि नाम पहिल्यै त्यो देख्ने कुनै काम नभएको पक्षमा खुलिसकेको हुन्छ। त्यसैले यहाँ उपलब्धता र गोपनीयता एकअर्काको बदलामा नभई सँगै जान्छन्।

टनेलले क्वेरीलाई VPN प्रदायकले नचलाउने रिजोल्भरकहाँ पनि लैजान सक्छ, किनभने टनेल समाधान गर्दैन, अगाडि पठाउँछ। अगाडि पठाउने होस्टले क्वेरी स्पष्ट पाठमा देख्छ र त्यसपछि आफ्नै जडान अगाडि खोल्छ, जसले अर्को चरण जोगाउँछ तर पहिलो जोगाउँदैन।

मार्ग र प्राप्तकर्ता सँगै जाँच्नुहोस्

कन्फिगरेसन होइन, प्याकेट हेर्नुहोस्। प्रणालीलाई कुन रिजोल्भर प्रयोग हुनेछ भनेर सोध्नुहोस्, त्यसपछि क्वेरी साँच्चै अपेक्षित इन्टरफेसबाट अपेक्षित ठेगानातिर गएको पुष्टि गर्नुहोस्।

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

यदि क्याप्चरले टनेल सक्रिय रहँदा क्वेरी भौतिक इन्टरफेस छोडिरहेको देखाउँछ भने, रिजोल्भरको सूचीले जे भने पनि ब्याकअपले टनेललाई छल्यो। यदि यो टनेलको इन्टरफेसमा देखिन्छ भने, प्रश्न दूरको छेउ कसले चलाउँछ र के राख्छ भन्ने हुन्छ।

एउटा भित्री र एउटा सार्वजनिक नामका लागि जाँच दोहोर्याउनुहोस्। भित्री क्वेरी त्यही ठाउँ हो जहाँ ब्याकअप कन्फिगरेसनले प्रायः आफूलाई देखाउँछ, किनभने जवाफ दिन नसक्ने रिजोल्भरले पनि प्रश्न पाउँछ।

ब्याकअपलाई अनुमति दिनुपर्ने हो कि होइन निर्णय गर्नुहोस्

यदि शर्त यो हो कि रोजेको रिजोल्भर उपलब्ध नहुँदा समाधान रोकिनुपर्छ भने, बन्द रूपमा असफल हुने प्रवर्तन नीति तोक्नुहोस् र परिणाम स्वीकार्नुहोस्: अवरोधका बेला नाम समाधान हुनेछैनन्। यो खराबी होइन, जानाजान गरिएको उपलब्धताको साटासाट हो, र डिजाइनले यो अवरोध हुनुअघि नै भन्नुपर्छ।

यदि शर्त मात्र यो हो कि क्वेरी टनेलबाहिर जानु हुँदैन भने, टनेलबाट पुगेको सार्वजनिक रिजोल्भर स्वीकार्य हुन सक्छ, बशर्ते अपरेटर र उसको भण्डारण नीति बुझिएको होस्। यस्तो स्वीकृति तेस्रो पक्षबारे निर्णय हो, क्रिप्टोग्राफीबारे भनाइ होइन, र यो गोपनीयताको दाबी भएको व्यक्तिको हो। यदि भित्री नामहरू चलिरहनुपर्ने भए, ब्याकअप त्यो रिजोल्भरमा हुनुपर्छ जसले भित्री जोन राख्छ, जसको सामान्य अर्थ ब्याकअपको लक्ष्य अर्को ठेगाना परिवार होइन, अर्को सर्भर हो।

नतिजा व्यवहारबारे एक वाक्यको रूपमा अभिलेख गर्नुहोस्: सामान्य सञ्चालनमा कुन रिजोल्भरले क्वेरी पाउँछ, असफलतापछि कुनले, र दोस्रो अवस्थामा भित्री नाम समाधान हुन्छन् कि हुँदैनन्। अन्तमा पृष्ठ लोड गर्ने चुहावट परीक्षणले त्यो वाक्यभन्दा कम प्रमाणित गर्छ, किनभने पृष्ठ कहिल्यै सोध्नु नहुने रिजोल्भरमार्फत पनि लोड हुन सक्छ।