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 अपयशी ठरले असे म्हणणारा अहवाल किमान तीन वेगवेगळ्या कारणांसह लक्षणाचे वर्णन करतो।