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 विफल होने की रिपोर्ट कम से कम तीन अलग कारणों वाले लक्षण का वर्णन करती है।