VPN किल स्विच पोर्ट 53 ब्लॉक करे तो DNS हल नहीं होता
किल स्विच जानबूझकर DNS ब्लॉक कर सकता है। केवल टनल के भीतर हल होने की तुलना स्थानीय रिज़ॉल्वर अपवाद से करें, फिर तय करें कि वास्तव में कौन-सी परत विफल हुई।
जब किल स्विच टनल गिरा देता है, तो वह DNS का रास्ता भी साथ ले जाता है, और पीछे बचा रिज़ॉल्वर शायद ही वह होता है जिसकी आप अपेक्षा करते हैं। दो डिज़ाइन उस पल को बहुत अलग तरह से संभालते हैं: टनल के भीतर न होने वाले हर DNS पैकेट को ब्लॉक करना, याएक रिज़ॉल्वर को अपवाद के रूप में खड़ा रहने देना। दोनों ही तर्कसंगत हैं। ब्राउज़र टैब से लक्षण लगभग एक जैसे दिखते हैं, इसलिए पहला काम यह पता करना है कि आपने वास्तव में कौन-सा डिज़ाइन लागू किया है।
मैं यह अंतर अपने सामने रखता हूँ, क्योंकि सुधार दोनों हालत में उल्टा है। एक डिज़ाइन को चौड़ा अपवाद चाहिए, दूसरे को संकरा। अनुमान लगाने पर आपको या तो निजता गँवानी पड़ती है या पूरी दोपहर।
एक ही खराबी के लिए दो DNS डिज़ाइन
डिज़ाइन A रिज़ॉल्वर को टनल के पीछे की एक और सेवा मानता है। फ़ायरवॉल नियम UDP और TCP 53 की अनुमति केवल टनल इंटरफ़ेस पर देते हैं, और क्लाइंट को दिया गया पता टनल के भीतर का रिज़ॉल्वर होता है। टनल गिरने पर लुकअप रुक जाते हैं, और यही इच्छित परिणाम है, कोई खराबी नहीं।
डिज़ाइन B स्थानीय नेटवर्क पर एक रिज़ॉल्वर पहुँच के भीतर रखता है, आमतौर पर 192.168.1.1 पर राउटर या 127.0.0.53 पर ऑपरेटिंग सिस्टम का स्टब, इस तर्क पर कि नाम-समाधान को टनल के साथ नहीं मरना चाहिए। घरेलू LAN में यह सुविधाजनक है, जहाँ राउटर पूरे घर के लिए हल करता है। होटल या हवाई अड्डे के Wi-Fi पर वही अपवाद किसी और के सर्वर की ओर इशारा करता है, और आपका टाइप किया हर नाम खुल जाता है, भले ही आपका वेब ट्रैफ़िक ब्लॉक रहे।
सीमा यह है कि रिज़ॉल्वर किसका है। स्थानीय पर भरोसा हो तो अपवाद छोटा और ईमानदार छेद है। भरोसा न हो तो केवल-टनल डिज़ाइन ही टिकता है, और कीमत यह है कि गिरी हुई टनल सारे नाम साथ ले जाती है।
VPN क्लाइंट की अपनी लुकअप अब भी क्यों काम करती है
क्लाइंट को टनल बनने से पहले गेटवे का होस्टनाम हल करना पड़ता है, इसलिए सख्त ब्लॉक को क्लाइंट के बूटस्ट्रैप रास्ते को नहीं ढकना चाहिए। ज़्यादातर क्लाइंट या तो एंडपॉइंट पता कैश करते हैं या उस एक होस्ट के लिए दस्तावेज़ी बूटस्ट्रैप अपवाद देते हैं। यदि आपका नियम-समूह वह लुकअप ब्लॉक कर दे, तो टनल कभी वापस नहीं आती और लॉग ऐसा क्लाइंट दिखाते हैं जो अपने ही सर्वर तक नहीं पहुँच पाता, जो नीति की खराबी है, DNS की नहीं।
स्प्लिट DNS दूसरी जगह है जहाँ यह दिखता है। क्लाइंट एक आंतरिक ज़ोन को निजी रिज़ॉल्वर पर धकेलता है और बाकी सब सिस्टम रिज़ॉल्वर पर छोड़ देता है। गिरने के बाद सार्वजनिक नाम शायद अब भी हल हों, जबकि आंतरिक नाम समय-सीमा पर विफल हों, क्योंकि निजी ज़ोन के पास कोई रूट नहीं बचा। उपयोगकर्ता के लिए यह "VPN ने इंटरनेट तोड़ दिया" है; रिज़ॉल्वर लॉग के लिए यह वह क्वेरी है जो कभी पहुँची ही नहीं।
systemd-resolved के अंतर्गत आप विभाजन सीधे देख सकते हैं।resolvectl statusप्रति-लिंक DNS सर्वर और रूटिंग डोमेन सूचीबद्ध करता है, और टनल गिरने के बाद आंतरिक डोमेन ऐसे लिंक के सर्वर की ओर इशारा करता रहता है जो अब मौजूद नहीं है। 127.0.0.53 पर स्टब क्वेरी अब भी स्वीकार करता है, फिर ऐसे अपस्ट्रीम की प्रतीक्षा करता है जो उत्तर नहीं देगा, और इसीलिए विफलता तुरंत लौटने के बजाय कुछ सेकंड लेती है।
एन्क्रिप्टेड DNS पैकेट फ़िल्टर को नहीं टालता
DNS over HTTPS और DNS over TLS 443 और 853 पर चलते हैं, इसलिए पोर्ट 53 ब्लॉक करने वाला नियम उनके बारे में कुछ नहीं कहता। पोर्ट के आधार पर "DNS" ब्लॉक करना पोर्ट की नीति है, नाम-समाधान की नहीं। यदि आपका किल स्विच टनल के बाहर का सारा ट्रैफ़िक ब्लॉक करता है, तो DoH संयोग से ढक जाता है। यदि आपने कैप्टिव पोर्टल या सार्वजनिक रिज़ॉल्वर के लिए छूट निकाली है, तो नहीं।
क्लाइंट-पक्ष के नियंत्रण सस्ता रास्ता हैं। Firefox अपना DoH रिज़ॉल्वर छोड़ देता है जब कैनरी नामuse-application-dns.netहल नहीं होता, और इसीलिए प्रबंधित नेटवर्क उस डोमेन को NXDOMAIN के रूप में प्रकाशित करते हैं; एंटरप्राइज़ नीति उसे बंद करके पिन भी कर सकती है। Android Private DNS और Chrome के सुरक्षित DNS के अपने स्विच और अपने डिफ़ॉल्ट हैं। उन्हें बंद करना रिज़ॉल्वर पतों के पीछे भागने से अधिक भरोसेमंद है, क्योंकि पतों की सूची बदलती है और आपका नियम-समूह नहीं।
इसका एक रूप ऐसा भी है जो लीक से जुड़ा ही नहीं है। पिन किए गए रिज़ॉल्वर वाले ऐप को वहाँ पहुँचने के लिए अब भी नेटवर्क रास्ता चाहिए। एन्क्रिप्शन बदलता है कि क्वेरी कौन पढ़ सकता है, यह नहीं कि पैकेट मशीन छोड़ सकता है या नहीं, इसलिए पूरे डिवाइस का ब्लॉक सेटिंग को छुए बिना उसे हरा देता है।
लक्षण को परत से मिलाएँ
ज़्यादातर रिपोर्ट एक वाक्य में आती हैं, और वह वाक्य आमतौर पर परत का नाम पहले ही बता देता है। नीचे की तालिका वही है जो मैं कोई नियम छूने से पहले देखता हूँ; मक़सद यह तय करना है कि क्वेरी ब्लॉक हुई, ग़लत दिशा में गई, या भेजी ही नहीं गई।
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
पहली दो पंक्तियाँ वही हैं जिनका लोग ग़लत निदान करते हैं। ख़ामोश गिरावट और इंकार दोनों ब्राउज़र में "DNS टूटा है" जैसे दिखते हैं, पर उनमें से सिर्फ़ एक का अर्थ है कि आपका किल स्विच अपना काम कर रहा है। इंकार का अर्थ है कि किसी ने उत्तर दिया, इसलिए ब्लॉक वहाँ नहीं है जहाँ आप सोचते हैं।
रिज़ॉल्वर नीति बहाल करें, फिर उसे सिद्ध करें
डिज़ाइन ठीक करें, लक्षण नहीं। केवल-टनल समाधान के लिए टनल इंटरफ़ेस पर 53 की अनुमति दें, टनल कॉन्फ़िगरेशन के साथ आंतरिक रिज़ॉल्वर धकेलें, और भौतिक लिंक को बिना किसी DNS छूट के छोड़ दें। wg-quick में रिज़ॉल्वर को इंटरफ़ेस कॉन्फ़िगरेशन में लिखने वाली पंक्तिDNS =है, इसलिए जो टनल उसे छोड़ देती है वह पुराने रिज़ॉल्वर को उसकी जगह रहने देती है और हर क्वेरी ग़लत रास्ते पर जाती है।wg-quick मैनुअलहर प्लेटफ़ॉर्म के लिए उस व्यवहार को दस्तावेज़ करता है।
फिर इस क्रम में जाँचें। Linux परresolvectl statusसक्रिय लिंक दिखाता है,dig +short example.comसार्वजनिक नाम जाँचता है,dig @10.8.0.1 internal.example.comनिजी नाम जाँचता है, औरsudo tcpdump -ni any port 53दिखाता है कि दोनों चलाते समय पैकेट कौन-सा इंटरफ़ेस इस्तेमाल करते हैं। Windows परGet-DnsClientServerAddress -AddressFamily IPv4औरResolve-DnsName example.comवही दो तथ्य देते हैं: कौन कॉन्फ़िगर है, और कौन उत्तर देता है।
नकारात्मक परीक्षण से समाप्त करें। टनल डिस्कनेक्ट करें, पुष्टि करें कि नया सार्वजनिक नाम विफल होता है, पुष्टि करें कि निजी नाम विफल होता है, औरपुष्टि करें कि पोर्ट 53 का कोई पैकेट भौतिक एडाप्टर से बाहर नहीं गया। जो ब्लॉक केवल कैश किए उत्तरों के लिए टिकता है, वह टिकता ही नहीं।
टिकट बंद करने से पहले चेकलिस्ट:
- खराबी के दौरान इस्तेमाल हुआ रिज़ॉल्वर वही है जो नीति चाहती है।
- क्लाइंट की अपनी एंडपॉइंट लुकअप अब भी अनुमत है, कैश या अपवाद से।
- DoH और DoT या तो ब्लॉक में शामिल हैं या नीति से बंद हैं।
- टनल जाने के बाद निजी ज़ोन बंद होकर विफल होते हैं, खुले नहीं।