VPN DNS फिल्टर: नावे ब्लॉक केल्याने जाहिराती ब्लॉक होत नाहीत

dnsmasq ची एक ओळ नावाला NXDOMAIN ने उत्तर देऊ शकते, आणि संपूर्ण यंत्रणा एवढीच आहे। ती कधीही HTML वाचत नाही, विनंतीचा मार्ग तपासत नाही आणि एखादे अनुप्रयोग आधीच उघडलेल्या जोडणीचे काय करते हेही पाहत नाही। त्यामुळे त्याची ब्राउझर विस्ताराशी तुलना करणे म्हणजे दोन वेगळ्या कामांची तुलना। एक नाव सोडवले जाईल का हे ठरवते; दुसरे त्यानंतर काय होते हे ठरवते।

नाव फिल्टर प्रत्यक्षात काय नियंत्रित करतो

शेवटच्या स्लॅशनंतर काहीही नसलेला address=/metrics.example/ पर्याय सोडवणाऱ्याला त्या नावासाठी आणि त्याच्या उपडोमेनसाठी NXDOMAIN परत करायला भाग पाडतो। पत्ता रिकामा ठेवणे हा महत्त्वाचा भाग आहे: यामुळे क्लायंटना असंबंधित पर्यायी सर्व्हरकडे पाठवणे किंवा लूपबॅक पत्ता खरा गंतव्यस्थान म्हणून दाखवणे टळते। dnsmasq चे पुस्तिका हा प्रकार रीडायरेक्ट नव्हे, तर नकारात्मक उत्तर म्हणून वर्णन करते।

नियम जे काही करू शकतो ते याच एका निर्णयातून येते। या सोडवणाऱ्याला विचारणाऱ्या क्लायंटला नकारात्मक उत्तर मिळते; दुसऱ्या सोडवणाऱ्याला विचारणाऱ्या क्लायंटला तो सोडवणारा जे सांगेल ते मिळते। अनुप्रयोग कोणता मार्ग, क्वेरी स्ट्रिंग किंवा खाते वापरला असता हे फिल्टरला माहीत नाही।

ही सूक्ष्मता महत्त्वाची आहे, कारण एकच होस्टनाव अनेकदा अनेक हेतू पूर्ण करते। साइन-इन एंडपॉइंट, प्रतिमा आणि ट्रॅकिंग एकच डोमेन सामायिक करू शकतात, आणि संपूर्ण नाव काढणारा नियम त्यासोबत कार्यप्रवाहही काढू शकतो। नाव-स्तराच्या धोरणाला हा व्यवहार स्वीकारावा लागतो किंवा अधिक अरुंद नावे निवडावी लागतात।

क्लायंट-साइड ब्लॉकर वेगळा कुठे आहे

ब्राउझर विस्तार विनंती बाहेर पडण्यापूर्वी पाहतो, त्यामुळे तो URL मार्ग जुळवू शकतो, विशिष्ट विनंती रद्द करू शकतो आणि निकाल दाखवणारा घटक लपवू शकतो। तो example.com/article ला परवानगी देताना example.com/ads/ नाकारू शकतो, जे कोणतेही DNS उत्तर व्यक्त करू शकत नाही। मार्ग-स्तराची ही दृष्टी हीच अशी क्षमता आहे जी सोडवणाऱ्याकडे अजिबात नाही। एका साधनासाठी तयार केलेली फिल्टर यादी दुसऱ्यात क्वचितच तशीच वागते याचेही हेच कारण।

किंमत व्याप्ती आहे। ते संरक्षण एका ब्राउझरमध्ये, एका प्रोफाइलमध्ये, एका उपकरणावर राहते आणि वापरकर्ता दुसऱ्या अनुप्रयोगाकडे गेल्यावर ते नाहीसे होते। गेटवेवर संरचित DNS फिल्टर गेटवेचा सोडवणारा वापरणाऱ्या प्रत्येक उपकरणाला व्यापते, जिथे कोणताही विस्तार स्थापित करता येत नाही अशा उपकरणांसह।

दोन्हीपैकी कोणतीही व्यवस्था स्वतःपुरती पूर्ण नाही। DNS फिल्टर पृष्ठाने आधीच पाठवलेला ओळखकर्ता काढू शकत नाही, आणि ब्राउझर विस्तार तो कधीही लोड न करणाऱ्या अनुप्रयोगाचे संरक्षण करू शकत नाही।

सोडवणाऱ्याचा मार्ग यापैकी काही लागू होते का हे ठरवतो

VPN DNS सर्व्हर जाहीर करूनही प्रत्येक क्वेरी मिळेलच असे नाही। एन्क्रिप्टेड DNS संरचित केलेला ब्राउझर, स्वतःचा सोडवणारा असलेला अनुप्रयोग किंवा गेटवे वगळणाऱ्या नेटवर्क मार्गावरील उपकरण—सर्व दुसरीकडे पाहतील। मोबाइल प्लॅटफॉर्म टनेल सुचवते ते शांतपणे रद्द करणारी खाजगी-DNS सेटिंग जास्ताधिक देत आहेत।

म्हणून धोरण नव्हे, मार्ग तपासा। इच्छित सोडवणाऱ्याला थेट गेटवेवरून विचारा, नंतर क्लायंटवरून विचारून तुलना करा, आणि नंतर ब्लॉक व्हायला हवे असे नाव वापरकर्त्याने चालवलेल्या अनुप्रयोगात खरोखर अयशस्वी होते का ते पहा।

कॅशे केलेली उत्तरे आणि उघडे सॉकेट हे गोंगाटाचे बनवतात। जे पृष्ठ आधीच त्याची संसाधने लोड करून झाले आहे ते नियम बदलल्यानंतरही चालू राहील, म्हणून जुन्या टॅबला पुन्हा लोड करण्यापेक्षा नवीन जोडणी चांगली चाचणी आहे।

निकाल जाहीर करण्यापूर्वी दोन्ही दिशा तपासा

हेतुपुरस्सर ब्लॉक केलेले दस्तऐवजी नाव, परवानगी असलेले सार्वजनिक नाव आणि सेवेला आवश्यक असलेले खाजगी नाव वापरा:

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

ब्लॉक केलेल्या नावासाठी रिकामे उत्तर, सार्वजनिकासाठी सामान्य पत्ता आणि अंतर्गतासाठी खाजगी पत्ता—एकत्रितपणे दाखवतात की फिल्टरिंग, अपस्ट्रीम रिझोल्यूशन आणि स्थानिक नोंदी सर्व काम करत आहेत। तिन्ही अयशस्वी झाल्यास तुम्ही फिल्टर नव्हे, तर अपस्ट्रीम किंवा श्रोत्याची अडचण पाहत आहात।

तुम्ही अंतर्गत प्रकाशित करता त्यातील प्रत्येक गोष्टीत दावा अरुंद ठेवा। हे सोडवणाऱ्यावरील डोमेन फिल्टरिंग आहे, सामग्री तपासणी नव्हे, मार्ग फिल्टरिंग नव्हे, आणि कोणीही ट्रॅक होत नाही असे वचनही नव्हे। धोरणाचा मालक, अपवादाचा मार्ग आणि क्वेरी साठवण्याचा कालावधी नियमांसोबत नमूद करा, कारण प्रत्येक शोध नोंदवणाऱ्या फिल्टरची स्वतःची गोपनीयता किंमत असते।