VPN चा DNS विरुद्ध ब्राउझरचा DoH: गळती चाचणी तुम्हाला काय सांगू शकत नाही
गळती चाचणीचा पत्ता फक्त कोणत्या रिझोल्व्हरने उत्तर दिले हे दाखवतो। एन्क्रिप्टेड क्वेरी, विभाजित DNS आणि ब्राउझर धोरण ठरवतात की खाजगी नावे अजूनही सोडवली जातात का।
गळती चाचणीचे पान म्हणते तुमचा DNS ठीक आहे, ब्राउझरचा बॅज म्हणतो सुरक्षित आहे, आणि अंतर्गत विकी तरीही लोड होत नाही। तिन्ही एकाच वेळी खरे असू शकतात, कारण रिझोल्व्हरचा पत्ता हा त्याला निवडणारे धोरण किंवा क्वेरीने घेतलेला मार्ग यापैकी काहीही नाही। लोक ज्याला DNS गळती म्हणतात तो प्रत्यक्षात एकच प्रश्न आहे: नाव कोणत्या रिझोल्व्हरला मिळाले, आणि ती निवड हेतुपुरस्सर होती का? हे सोडवायला तीन तपासण्या लागतात, आणि फक्त शेवटच्यातच सेटिंग बदलणे असते।
पहिला गैरसमज: बॅज तुमच्या रिझोल्व्हरचे नाव सांगतो
गळती चाचणी एक चाचणी नाव सोडवते आणि ज्या पत्त्याने उत्तर दिले त्याची नोंद करते। ती तो रिझोल्व्हर निवडणाऱ्या धोरणाची नोंद करत नाही, आणि जेव्हा क्वेरी DNS over HTTPS मध्ये गुंडाळलेली असते, तेव्हा मार्गावरील मधले बॉक्स नाव पाहूही शकत नाही। दोन पूर्णपणे भिन्न मशिन्स एकच दिलासा देणारा बॅज देतात: एकात VPN ने 10.8.0.1 पाठवले आणि ब्राउझर ते वापरतो, दुसऱ्यात ब्राउझरने सिस्टम यादी दुर्लक्षित केली आणि नाव टनेलमधून आपल्या एन्क्रिप्टेड पुरवठादाराकडे पाठवले।
खाजगी नाव अयशस्वी होण्याच्या क्षणी हा फरक महत्त्वाचा ठरतो। पहिल्या रचनेत VPN रिझोल्व्हर कॉर्पोरेट झोनसाठी उत्तर देतो; दुसऱ्यात ब्राउझरने त्याला कधीच विचारले नाही, त्यामुळे लहान होस्टनाव सोडवले जात नाही आणि अयशस्वीपणा तुटलेल्या VPN सारखा दिसतो। ही तपासणी दुसरी गळती चाचणी नाही, ती फक्त एका रिझोल्व्हरला माहीत असलेल्या नावाची शोध आहे।
दुसरा गैरसमज: ब्राउझर टनेल सोडतो
DNS पत्ता निवडतो, राउटिंग जोडणी वाहून नेते, आणि हे दोन वेगळे स्तर आहेत। सार्वजनिक DoH पुरवठादाराकडे पाठवलेली क्वेरी अजूनही राउट करण्यायोग्य पत्त्याकडे जाणारा TCP पोर्ट 443 आहे। तुमचा राउट तक्ता डीफॉल्ट मार्ग टनेलमध्ये पाठवत असल्यास ती क्वेरीही टनेलमधून जाते। रिझोल्व्हरचा ब्रँड मार्ग ठरवत नाही।
ब्राउझरचा DoH बदलतो तो नावांचा प्राप्तकर्ता। तो खरा गोपनीयता निर्णय आणि खरा धोरण निर्णय आहे, पण राउटिंग बायपास नाही। जर तुमची अट असेल की नावे VPN ऑपरेटरकडेच राहिली पाहिजेत, तर दुसऱ्या कोणाला पाठवलेली एन्क्रिप्टेड क्वेरी ती अट पूर्ण करत नाही, तरीही ती प्रत्यक्ष जोडणीसाठी टनेल वापरते।
तिसरा गैरसमज: प्रत्येक VPN प्रत्येक ब्राउझरवर मात करतो
ब्राउझरमधील सुरक्षित DNS ला मोड असतात, स्विच नाही: बंद, फॉलबॅकसह डीफॉल्ट पुरवठादार, सानुकूल टेम्पलेट, किंवा ऑपरेटिंग सिस्टम किंवा संस्थेने लादलेले धोरण। फॉलबॅक प्रकरणच अधूनमधून अहवाल निर्माण करते। एन्क्रिप्टेड एंडपॉइंट उपलब्ध नसल्यास ब्राउझर सिस्टम रिझोल्व्हरकडे परत जाऊ शकतो, त्यामुळे तोच लॅपटॉप सोमवारी खाजगी नाव बरोबर सोडवतो आणि मंगळवारी सोडवत नाही।
त्याच वेळी, बहुतेक VPN क्लायंट जोडणी वर येताच सिस्टम रिझोल्व्हर सेट करतात आणि ती पडल्यावर आधीचा पुनर्संचयित करतात। सानुकूल एन्क्रिप्टेड रिझोल्व्हर ठेवणारा ब्राउझर तो पुनर्संचय पाहतही नाही। म्हणूनच तोच प्रोफाइल दोन लॅपटॉपवर वेगळे वागते आणि म्हणूनच resolv.conf बरोबर दिसतो, तर ब्राउझर अजूनही दुसऱ्या कोणालातरी विचारत असतो।
resolvectl status # per-link DNS servers and split-DNS domains
scutil --dns | head -30 # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1 # ask the VPN resolver directlyजोडलेले असताना त्या चालवा, प्रत्येक रिझोल्व्हर कोणत्या डोमेनवर दावा करतो ते नोंदवा, आणि ब्राउझर आपल्या मोडबद्दल जे सांगतो त्याशी तुलना करा। Mozilla चे DoH दस्तऐवज ब्राउझरचे डीफॉल्ट आणि फॉलबॅक वर्तन कसे असावे याचे वाजवी वर्णन आहे।
निर्णयाला तीन इनपुट आहेत, एक नाही
खाजगी नावे, ऑपरेटरवरील विश्वास आणि पोहोच हे योग्य रचना ठरवतात। फक्त VPN रिझोल्व्हरला माहीत असलेली नावे विभाजित DNS लादतात: खाजगी प्रत्यय पाठवलेल्या रिझोल्व्हरकडे जातो, आणि बाकी सर्व सार्वजनिक नावांसाठी तुम्ही निवडलेल्या धोरणाचे पालन करते। ऑपरेटरवरील विश्वास सार्वजनिक नावेही त्याच रिझोल्व्हरकडे की वेगळ्या सेवेकडे जावीत हे ठरवतो। पोहोच तुम्ही निवडलेला एन्क्रिप्टेड रिझोल्व्हर या नेटवर्कवर अजिबात वापरण्यायोग्य आहे का हे ठरवते।
| Condition | What it forces |
|---|---|
| Internal names must resolve | Split DNS: private suffixes to the VPN resolver, the rest to your chosen default |
| Queries must stay with one operator | Pin both the system resolver and the browser mode, and disable fallback |
| Resolver only reachable through the tunnel | Keep the pushed resolver; do not point DoH at an endpoint your routes exclude |
यातील कोणतीही ओळ सार्वत्रिक शिफारस नाही। VPN चालवणारा रिझोल्व्हर निरीक्षणे त्या ऑपरेटरकडे केंद्रित करतो; वेगळी सेवा विचारलेल्या नावांचा आणखी एक प्राप्तकर्ता जोडते। दोन्हीपैकी कोणतीही रचना धारणाबद्दल काहीही सिद्ध करत नाही, जोपर्यंत तुम्ही धोरण वाचत नाही।
प्रत्येक प्रोफाइलसाठी निर्णय लिहून ठेवा, कारण ही सेटिंग्ज सरकतात। गेल्या महिन्यात रिझोल्व्हर पाठवणारे प्रोफाइल आज काहीही पाठवणार नाही, आणि ब्राउझर अजूनही उत्तर देणारा जुना सानुकूल एंडपॉइंट आनंदाने ठेवेल। टिपीत रिझोल्व्हरचा पत्ता, त्याच्या मालकीचे प्रत्यय आणि ब्राउझरचा मोड असावा, सेवेचा ब्रँड नाही।
तुम्ही कॉन्फिगर केले असे वाटते ते धोरण तपासा
बॅजने नाही, नावाने तपासा। सिस्टम रिझोल्व्हरद्वारे सार्वजनिक नाव आणि खाजगी नाव सोडवा, नंतर तुम्ही वापरणार असलेल्या मोडमध्ये ब्राउझरच्या स्वतःच्या सुरक्षित DNS सेटिंगसह ते पुन्हा करा। खाजगी नाव फक्त ब्राउझरमध्ये अयशस्वी झाल्यास, एकही VPN सेटिंग न बदलता तुम्ही प्राप्तकर्त्याची विसंगती शोधली आहे।
मग पुन्हा कनेक्ट करा आणि पुनर्संचय तपासा, कारण हस्तांतरण बग तिथेच राहतात: डिस्कनेक्ट करा, आधीचा रिझोल्व्हर परत आल्याची खात्री करा, पुन्हा कनेक्ट करा, पाठवलेला रिझोल्व्हर परत आल्याची खात्री करा। शेवटी, व्यवस्थापित धोरण असलेला ब्राउझर असल्यास तपासा, कारण तो मोड तुमचा बदल पूर्णपणे नाकारू शकतो आणि गुपचूप आधीचा रिझोल्व्हर ठेवू शकतो।
नावांच्या जागेच्या प्रश्नापासून सुरुवात करा आणि यातील बहुतेक टाळाल। मशीनला अंतर्गत नावांपर्यंत पोहोचायचे असल्यास, ब्राउझरचा एन्क्रिप्टेड रिझोल्व्हर फक्त सार्वजनिक अर्ध्याबद्दलचा निर्णय आहे, आणि खाजगी अर्धा VPN ने जे पाठवले त्याजवळच राहतो।