स्प्लिट टनल ब्राउज़र को बाहर रखता है, उसके DNS प्रश्नों को नहीं

ब्राउज़र टनल से बाहर, सार्वजनिक IP पृष्ठ पुष्टि करता है कि उसका ट्रैफ़िक घर के कनेक्शन से बाहर जाता है, और आंतरिक विकी फिर भी नहीं खुलती। नाम विश्लेषण कहीं और गया, और वह कहीं और आमतौर पर वही रिज़ॉल्वर है जो VPN ने सेट किया। डेटा पथ और रिज़ॉल्वर पथ अधिकांश स्प्लिट-टनल डिज़ाइन में अलग निर्णय हैं। बहिष्करण को टूटा कहने से पहले जाँचें कि ब्राउज़र ने वास्तव में किसका उपयोग किया।

डेटा पथ और रिज़ॉल्वर पथ अलग होते हैं

बहिष्करण किसी ऐप्लिकेशन के पैकेट टनल से हटाता है, जो डेटा पथ पर रूटिंग और फ़ायरवॉल का निर्णय है। नाम विश्लेषण एक अलग खोज है: कोई प्रक्रिया सिस्टम के रिज़ॉल्वर से पूछती है, और वह रिज़ॉल्वर तय करता है कि कौन सा सर्वर प्रश्न पाएगा।

दोनों जानबूझकर और अलग हो सकते हैं। कोई कार्य परिनियोजन आंतरिक नामस्थान कॉर्पोरेट रिज़ॉल्वर पर रख सकता है और चुना हुआ सार्वजनिक ब्राउज़िंग टनल के बाहर भेज सकता है, ठीक इसलिए कि आंतरिक नाम कहीं और हल नहीं होते। उलझन वाला मामला उल्टा है: कोई सार्वजनिक साइट विफल होती है क्योंकि ब्राउज़र ने कभी उस रिज़ॉल्वर से नहीं पूछा जिसकी परिनियोजन अपेक्षा करता था। मार्ग और रिज़ॉल्वर अलग-अलग दर्ज करें, और आधी बहसें गायब हो जाएँगी।

पता लगाएँ कि कौन सी प्रक्रिया प्रश्न पूछती है

ब्राउज़र सिस्टम का रिज़ॉल्वर, अपनी एन्क्रिप्टेड DNS सेवा, या ऐसा रिज़ॉल्वर उपयोग कर सकता है जो ऑपरेटिंग सिस्टम प्रत्येक नेटवर्क के लिए निर्धारित करता है। पहला प्लेटफ़ॉर्म नीति का पालन करता है, दूसरा उस नीति को पूरी तरह बायपास करता है, और तीसरा इस पर निर्भर है कि प्रश्न किस लिंक पर रूट होता है।

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

परीक्षण से पहले प्रभावी कॉन्फ़िगरेशन पढ़ें: कौन से लिंक DNS सर्वर ले जाते हैं, कौन से नामस्थान दावा करते हैं, और क्या प्रति-नाम नीति डिफ़ॉल्ट को ओवरराइड करती है। लिनक्स पर स्प्लिट DNS रूटिंग डोमेन उपयोग करता है; विंडोज़ पर नाम विश्लेषण नीति तालिका नामस्थानों के लिए वही काम करती है। दोनों में से कोई लीक-परीक्षण पृष्ठ से दिखाई नहीं देता।

तय करें कि कौन सा रिज़ॉल्वर कौन सा नाम देखे

कुछ भी बदलने से पहले इच्छित मैपिंग लिखें: आंतरिक नाम कॉर्पोरेट रिज़ॉल्वर को, सार्वजनिक नाम उस सेवा को जिसे नीति अनुमति देती है, और अपवाद मालिक के साथ। उस सूची के बिना, लीक-परीक्षण का हर लेबल ऐसी नीति-बहस बन जाता है जिसे कोई सुलझा नहीं सकता।

फिर ब्राउज़र की अपनी सेटिंग जाँचें, क्योंकि ब्राउज़र में एन्क्रिप्टेड DNS ऑपरेटिंग सिस्टम के प्रश्न पाने से पहले लागू होता है। जिस उपयोगकर्ता ने कैप्टिव पोर्टल से बचने के लिए इसे चालू किया, उसने चुपचाप उस रिज़ॉल्वर को बदल दिया जिसे परिनियोजन ने चुना था। यह कॉन्फ़िगरेशन निर्णय है, लीक नहीं, और यह ब्लॉकलिस्ट के बजाय निर्णय का हक़दार है।

एक परीक्षण लेबल को हरा करने के लिए हर DNS फ़ील्ड फिर से न लिखें। लेबल एक क्षण में एक प्रक्रिया के एक प्रश्न का वर्णन करता है।

प्रश्न और कनेक्शन अलग-अलग सत्यापित करें

दोनों पथों को स्वतंत्र रूप से परखें। कनेक्शन परीक्षण डेटा मार्ग दिखाता है, और रिज़ॉल्वर परीक्षण दिखाता है कि नाम किसने पाया।

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

रिज़ॉल्वर से स्पष्ट रूप से भी पूछें, ताकि विफलता पथ के बजाय सर्वर को दी जा सके। फिर ब्राउज़र पुनः आरंभ करें और दोहराएँ, क्योंकि ऐप्लिकेशन नकारात्मक उत्तर कैश करते हैं और पुरानी विफलता स्थायी लगती है।

स्वीकृत परिवर्तन के बाद डेटा मार्ग और रिज़ॉल्वर के प्राप्तकर्ता को दो अलग पंक्तियों के रूप में तारीख के साथ दर्ज करें। यदि अगले पुनःकनेक्शन पर व्यवहार लौटता है, तो जो प्रोफ़ाइल इसे प्रदान करती है वही ठीक करने की चीज़ है, ब्राउज़र नहीं।