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 एकतर ब्लॉकमध्ये समाविष्ट आहेत किंवा धोरणाने बंद आहेत.
- टनेल गेल्यावर खाजगी झोन उघडे नाही, बंद स्थितीत अयशस्वी होतात.