VPN जडान हुनुअघि हटस्पटले DNS किन पुनर्निर्देशन गर्छ?
हटस्पटले आफ्नै नेटवर्कमा लुकअपहरू पुनःलेखन गर्छ, र कुनै पनि सुरुङ बन्नुअघि होस्टनाम इन्डपोइन्ट समाधान हुन्छ। प्रत्येक क्वेरीको जवाफ कुन रिजोल्भरले दियो पत्ता लगाउनुहोस्।
होटल नेटवर्कमा जोडिनुले तपाईंको सामु फरक फरक क्षणमा दुई DNS निर्णय राख्छ: साइन इन गर्दा यन्त्रले गर्ने लुकअपहरू, र सुरुङ उभिएपछि गरिने लुकअपहरू। हटस्पटले आफूले नियन्त्रण गर्ने नेटवर्कमार्फत पहिलोलाई प्रभाव पार्न सक्छ। दोस्रो क्लाइन्टको आफ्नै नीतिमा निर्भर गर्छ, जुन छुट्टै जाँच्ने विषय हो।
जडानलाई क्रममा हेर्नुहोस्, पहिलो DHCP लिजदेखि निजी नाम समाधान गर्ने क्वेरीसम्म। त्यसपछि समर्थन टिकटमा एउटै देखिने दुई असफलता स्पष्ट रूपमा अलग हुन्छन्: एउटा सुरुङ अघि भयो, अर्को त्यसभित्र भयो।
हटस्पटले के छुन सक्छ र के सक्दैन
पहुँच नेटवर्कले DHCP मा रिजोल्भर ठेगाना दिन्छ र त्यस ठेगानातर्फ पोर्ट 53 अवरोध गर्न सक्छ। यो हरेक असंरक्षित लुकअपलाई पोर्टल ठेगाना वा ब्लक पेजले जवाफ दिन पर्याप्त छ। इन्डपोइन्ट होस्टनामका रूपमा लेखिएको VPN क्लाइन्ट तोड्न पनि यो पर्याप्त छ।
हटस्पटले गर्न नसक्ने कुरा स्थापित सुरुङभित्र क्वेरी गएपछि त्यसलाई पढ्नु वा पुनःलेखन गर्नु हो, यदि सुरुङले साँच्चै त्यसलाई बोक्छ भने। अवरोध सादा पाठमा प्रश्न देख्नमा निर्भर छ।
क्वेरीहरू हटस्पटसँग सम्बन्ध नभएका कारणले पनि सुरुङ छोड्छन्: ब्राउजरको सुरक्षित DNS सेटिङ, कर्पोरेट प्रत्यय स्थानीय रिजोल्भरमा राख्ने split-DNS नियम, वा DNS सुरुङबाट बाहिर राख्न कन्फिगर गरिएको क्लाइन्ट। प्रत्येक क्लाइन्ट पक्षको छनोट हो, र बाहिरबाट हेर्दा प्रत्येक हटस्पटको हस्तक्षेपजस्तो देखिन्छ।
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
पहिलो लुकअप सुरुङ बन्नुअघि हुन्छ
होस्टनाम पाएको क्लाइन्टले पहिले त्यसलाई समाधान गर्नुपर्छ, र त्यो क्षणमा कुनै सुरुङले क्वेरीको रक्षा गर्दैन। हटस्पटले पोर्टल ठेगानाले जवाफ दिएमा वार्ता असफल हुन्छ वा अड्किन्छ। केही पनि जवाफ नदिएमा क्लाइन्टले नाम त्रुटि रिपोर्ट गर्छ र सुरुङ कहिल्यै सुरु हुँदैन। दुईमध्ये कुनै पनि नतिजाले अन्यथा निर्दोष देखिने खाली सुरुङ लग व्याख्या गर्छ।
अपरेटिङ सिस्टमहरूले आफ्नै जडान जाँच र पोर्टल पत्ता लगाउने काम पनि गर्छन्, जुन RFC 8910 र RFC 8952 मा वर्णन गरिएको छ, र ती अनुरोधहरू कुनै पनि VPN उभिनुअघि बाहिर जान्छन्। तिनीहरूलाई प्रोक्सी लगमा देख्नु चुहावटको प्रमाण नभई अपेक्षित व्यवहार हो।
व्यावहारिक उपाय क्लाइन्टलाई लुकअप नचाहिने इन्डपोइन्ट दिनु हो। त्यो असम्भव हुँदा, पहिले साइन इन पूरा गर्नुहोस् र त्यसपछि जडान गर्नुहोस्।
कुन रिजोल्भरले जवाफ दियो पत्ता लगाउनुहोस्
ब्राउजरलाई होइन, सिस्टमलाई सोध्नुहोस्, र क्वेरी दुई पटक चलाउनुहोस्: एक पटक यन्त्रले अहिले प्रयोग गरिरहेको रिजोल्भरमार्फत, एक पटक स्थिर ठेगानाविरुद्ध।
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
पहिलो आदेशको जवाफ तेस्रोभन्दा फरक भएमा स्थानीय रिजोल्भर अरू केही फर्काइरहेको छ भन्ने थाहा हुन्छ, र पुनर्निर्देशन गर्ने हटस्पटले ठ्याक्कै त्यही गर्छ। तेस्रोको असफलता पहिलोको सफलतासँगै भएमा पोर्टलतर्फ संकेत गर्छ: स्थानीय रिजोल्भरले साइन-इन ठेगाना दियो, तर बाहिर जाने पोर्ट 53 छोडियो। दुवैमा समय सकिनु भनेको प्रमाणीकरण पूरा नहुँदासम्म नेटवर्कले DNS छोड्छ।
जडान गरेपछि दोहोर्याउनुहोस् र तुलना गर्नुहोस्। क्यास गरिएको जवाफ संक्रमणमा टिक्छ, त्यसैले क्यास खाली गर्नुहोस् वा दोस्रो अवलोकनका लागि नयाँ नाम सोध्नुहोस्।
पछिका लुकअपहरू तपाईंले चाहेको मार्गमा राख्नुहोस्
DNS पनि समात्ने पूर्ण सुरुङ प्रोफाइल सबैभन्दा सरल व्यवस्था हो: हरेक एपको हरेक क्वेरी सुरुङले धकेल्ने रिजोल्भरमा जान्छ, र स्थानीय नेटवर्कले एन्क्रिप्ट गरिएको ट्राफिक मात्र देख्छ। जडान गरेपछि आन्तरिक र सार्वजनिक नाम समाधान गरेर, त्यसपछि दुवै जवाफलाई सुरुङ रिजोल्भरले एकलै फर्काउनेसँग तुलना गरेर यो प्रमाणित गर्नुहोस्।
Split-DNS लाई नियतसाथ लेखिएको डोमेन सूची चाहिन्छ: कर्पोरेट प्रत्ययहरू सुरुङमार्फत, बाँकी सबै स्थानीय रूपमा, र दुवैबीच कुनै ओभरल्याप छैन।
ब्राउजरको सुरक्षित DNS त्यो नीतिबाहिर छ, त्यसैले प्रोफाइल अनुमानित रूपमा चल्न त्यो बन्द हुनु आवश्यक भए, मेसिनका लागि होइन, त्यो प्रोफाइलका लागि बन्द गर्नुहोस्। सिस्टम रिजोल्भर सम्पादन गरेर होइन, ब्राउजर सेटिङमा गर्नुहोस्, ताकि परिवर्तन अर्को पटक देखियोस्। प्रत्येक परीक्षणका लागि एक लाइनमा जवाफ, रिजोल्भर र जडान चरण लेख्नुहोस्। होटलको Wi-Fi मा DNS असफल भयो भन्ने रिपोर्टले कम्तीमा तीन फरक कारण भएको लक्षण वर्णन गर्छ।