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 संयोगवश समेटिन्छ। क्याप्टिभ पोर्टल वा सार्वजनिक रिजोल्भरका लागि छुट निकाल्नुभएको छ भने समेटिँदैन।
क्लाइन्ट-पक्षीय नियन्त्रण सस्तो हतियार हो। क्यानरी नामuse-application-dns.netसमाधान नहुँदा Firefox आफ्नो DoH रिजोल्भर छोड्छ, र त्यसैले व्यवस्थित नेटवर्कहरूले त्यो डोमेन 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 अवरोधले समेटिएका छन् वा नीतिले बन्द छन्।
- टनेल गएपछि निजी जोन खुला होइन, बन्द अवस्थामा असफल हुन्छन्।