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 विनिर्देश तपाईंको पोर्ट नियमले नदेख्ने इन्क्रिप्टेड बाटोको सन्दर्भ हो।