VPN जोडल्यानंतरही Pi-hole जाहिराती ब्लॉक करत नाही: पाच तपासण्या

एका क्लायंटवर अजूनही जाहिराती दिसत आहेत, Pi-hole स्वतःला निरोगी जाहीर करत आहे, आणि टनेल सुरू आहे, त्यामुळे त्या क्लायंटचा ट्रॅफिक Pi मधून पाठवण्याची सहज प्रवृत्ती होते। हा चुकीचा वळण आहे। फिल्टरिंगला पॅकेट नाही, प्रश्न हवेत, आणि ज्या क्लायंटच्या क्वेरीज ISP च्या रिझोल्व्हरकडे जातात तो त्याचा ट्रॅफिक कुठेही वाहो, अफिल्टरच राहतो। ही यादी क्रमाने पूर्ण करा आणि जो पहिला टप्पा अपयशी होईल तिथेच थांबा, कारण आधीचा टप्पा तुटलेला असताना पुढचा टप्पा तुम्हाला काहीही सांगू शकत नाही।

1. क्लायंट प्रत्यक्षात वापरत असलेला रिझोल्व्हर वाचा

राउटरला नाही, क्लायंटला विचारा। Linux वर resolvectl status प्रत्येक लिंकचे DNS सर्व्हर आणि कोणती लिंक जिंकते ते छापते; एकटे /etc/resolv.conf सहसा 127.0.0.53 कडे निर्देश करणारे स्टब असते। Windows वर ipconfig /all प्रत्येक अडॅप्टरसाठी DHCP ने दिलेले सर्व्हर सूचीबद्ध करते, आणि macOS वर scutil --dns तेच स्कोपनुसार दाखवते। उत्तर Pi-hole चा पत्ता नसेल, तर तुमच्याकडे असाइनमेंटची समस्या आहे आणि टप्पा 2 ही ती जागा आहे।

सिस्टम रिझोल्व्हर बरोबर सेट असतानाही दोन गोष्टी त्याला हरवतात। स्वतःचे सुरक्षित DNS असलेले ब्राउझर (Chrome चा “Use secure DNS”, Firefox चा network.trr.mode) क्वेरीज HTTPS द्वारे सार्वजनिक रिझोल्व्हरकडे पाठवतात आणि पोर्ट 53 कधीही उघडत नाहीत। आणि क्लायंटवरच असलेला VPN क्लायंट त्याच्या टनेल इंटरफेसवर ~. राउटिंग डोमेनसह DNS सर्व्हर स्थापित करू शकतो, ज्यामुळे ती लिंक प्रत्येक नावासाठी अधिकृत होते।

ॲप्लिकेशन्स जो मार्ग घेतात तो तपासा, डीबग साधन जो मार्ग घेते तो नाही। resolvectl query example.com कोणत्या लिंकने उत्तर दिले ते दाखवते, आणि getent hosts example.com ॲप्लिकेशन जाते त्याच NSS मार्गाने जाते; macOS वर dscacheutil -q host -a name example.com scutil --dns सूचीबद्ध करत असलेले स्कोप्ड रिझोल्व्हर वाचते। नुसता dig हे करत नाही: तो /etc/resolv.conf वाचतो आणि प्रति-लिंक निवड वगळतो, त्यामुळे प्रत्येक ॲप्लिकेशन पुश केलेला रिझोल्व्हर वापरत असतानाही तो Pi-hole मधून उत्तर देऊ शकतो, आणि हीच ती नेमकी अडचण आहे ज्यासाठी ही यादी आहे। एका विशिष्ट सर्व्हरची चाचणी करण्यासाठी dig @192.168.1.53 ठेवा।

2. उत्तर कोण वाटतो याची खात्री करा

असाइनमेंट जे DHCP ला उत्तर देते त्याकडून येते। dnsmasq वर ती एक ओळ आहे, dhcp-option=6,192.168.1.53; राउटरच्या वेब UI मध्ये ते LAN DHCP विभागातील DNS फील्ड आहे। क्लायंट्सना ते दिसण्यापूर्वी नूतनीकरण करावे लागते। अनेक दिवस सुरू असलेले उपकरण अजूनही जुने लीज धरून ठेवते, आणि हाताने टाइप केलेला रिझोल्व्हर असलेले उपकरण ते कायम ठेवते। प्रसार गृहीत धरण्याऐवजी चाचणी क्लायंटवर नूतनीकरण करा।

IPv6 हा विसरला जाणारा अर्धा भाग आहे। राउटर जाहिराती स्वतःचा DNS सर्व्हर वाहू शकतात (RDNSS), आणि OpenWrt वर तो odhcpd चा ra_dns पर्याय आहे; IPv6 पसंत करणारा क्लायंट तो सर्व्हर वापरतो, तर नुकताच सेट केलेला DHCPv4 पर्याय न वापरला जाता राहतो। IPv6 DNS देण्यास तयार नसाल, तर फक्त DNS जाहिरात साफ करा: odhcpd मधील ra_dns, किंवा राउटर जाहिरातींना उत्तर देणाऱ्या कोणत्याही गोष्टीतील RDNSS पर्याय। संपूर्ण जाहिरात बंद केल्याने LAN मधून IPv6 ॲड्रेसिंगही निघून जाते, जे तुम्ही ठरवलेल्या बदलापेक्षा खूप मोठा बदल आहे, तर फक्त DNS पर्याय साफ केल्याने ॲड्रेसिंग अबाधित राहते आणि गहाळ RDNSS पॅकेट कॅप्चरमध्ये दिसू लागतो।

3. क्वेरी Pi-hole पर्यंत पोहोचते हे सिद्ध करा

Pi मधून केलेली क्वेरी नेटवर्क मार्गाबद्दल काहीही सिद्ध करत नाही। ती क्लायंटवरून चालवा आणि प्रतिसाद कोड वाचा:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

टाइमआउट फिल्टरिंग किंवा मार्गाकडे निर्देश करतो; REFUSED प्रवेश नियमाकडे; SERVFAIL Pi-hole च्या मागील अपस्ट्रीम रिझोल्व्हरकडे; क्वेरी लॉगमध्ये कधीही न दिसणारे बरोबर उत्तर म्हणजे क्लायंटने दुसरे काही विचारले। UDP आणि TCP 53 तपासा, कारण मोठे उत्तर आणि काही रिझोल्व्हर TCP वर परत जातात, आणि Pi-hole कंटेनरमध्ये चालत असेल तर दोन्ही प्रकाशित करा। फक्त UDP व्यापणारे मॅपिंग पॅकेट लॉससारखी अधूनमधून अपयशे निर्माण करते।

नंतर Pi-hole चा ऐकण्याचा मोड तो अजिबात उत्तर देतो का हे ठरवतो। फक्त-स्थानिक मोडमध्ये dnsmasq थेट जोडलेल्या सबनेटवर नसलेल्या स्रोतांच्या क्वेरीज दुर्लक्षित करतो, आणि दुसऱ्या राउटरमागील किंवा टनेलमधून येणारा क्लायंट नेमका असाच दिसतो: क्लायंटची वेळ संपते आणि क्वेरी कधीही लॉगपर्यंत पोहोचत नाही। तरीही REFUSED म्हणून दिसणारी क्वेरी प्रवेश यादीने किंवा फायरवॉल नियमाने नाकारली आहे। सर्व स्रोतांना परवानगी देणे हा नेहमीचा उपाय आहे, सोबत पोर्ट 53 तुमच्या स्वतःच्या सबनेटपुरता मर्यादित ठेवणारा फायरवॉल नियम।

4. टनेलने उत्तर बदलले आहे की गिळले आहे ते तपासा

ही अशी गोष्ट आहे ज्यात दोन्ही लक्षणे लपलेली असतात। जेव्हा राउटर स्वतः VPN क्लायंट असतो, तेव्हा पुश केलेला DNS पर्याय टनेल वर येण्याच्या क्षणी LAN सेटिंग ओलांडू शकतो: OpenVPN सर्व्हर dhcp-option DNS पुश करतात, आणि WireGuard प्रोफाइल स्वतःची DNS नोंद घेतात। टनेल सुरू असताना राउटरचा प्रभावी रिझोल्व्हर वाचा, त्यापूर्वी नाही, आणि LAN पृष्ठ जे दावा करते ते दुर्लक्षित करा।

दुसरी खराबी बदल नाही, पोहोच आहे। टनेलच्या परवानगी असलेल्या प्रीफिक्समध्ये तुमचे LAN सबनेट असल्यास, राउटरकडे 192.168.1.53 साठीच्या क्वेरीज टनेलमध्ये पाठवणारा मार्ग आहे, आणि पलीकडे परतण्याचा मार्ग नाही: टनेल निरोगी असतानाही क्वेरीजची वेळ संपते। उलटे तेव्हा होते जेव्हा Pi-hole टनेल वाहत नाही अशा सबनेटमध्ये असतो। DNS पुन्हा हाताळण्यापूर्वी पत्त्याची टनेलच्या परवानगी असलेल्या प्रीफिक्स आणि राउटरच्या रूट टेबलशी तुलना करा।

दोन्ही नाही, एक उपाय निवडा। एकतर टनेल DNS पासून दूर ठेवा — OpenVPN वर pull-filter ignore “dhcp-option DNS” आणि WireGuard वर AllowedIPs मध्ये LAN प्रीफिक्स नाही —, किंवा पुश केलेला रिझोल्व्हर स्वीकारा आणि त्या राउटरमागील क्लायंटसाठी स्थानिक फिल्टरिंग सोडून द्या। तुम्ही जे निवडाल ते प्रोफाइलच्या शेजारी लिहा, कारण पुढील व्यक्ती त्यात संपादन करेल ती नाहीतर चुकून निर्णय उलटवेल।

5. पुन्हा जोडल्यानंतर चाचणीची पुनरावृत्ती करा

क्लायंटवरून क्वेरी करा, तो क्लायंट Pi-hole च्या लॉगमध्ये दिसतो याची खात्री करा, नंतर ब्लॉक होणे आवश्यक असलेले डोमेन रिझोल्व्ह करा आणि खऱ्या उत्तराऐवजी ब्लॉकिंग उत्तर मिळते का ते तपासा। टनेल पुन्हा जोडा आणि त्या दोनच क्वेरीज चालवा, कारण पुढच्या जोडणीपर्यंतच टिकणारे रिझोल्व्हर सेटिंग हे चुकीच्या स्तरावर लागू केलेल्या उपायाचे नेहमीचे फलित आहे।

टनेलवर अवलंबून नसलेला दुय्यम रिझोल्व्हर मार्ग ठेवा, जेणेकरून Pi-hole बंद पडल्यास ब्राउझिंग पूर्ण थांबण्याऐवजी अफिल्टर ब्राउझिंगपर्यंत घसरेल। चाचणी दोनदा उत्तीर्ण होईपर्यंत मागील DHCP आणि रिझोल्व्हर मूल्ये ठेवा; रात्रीच्या जेवणाच्या वेळी घरचे इंटरनेट तोडणारा बदल एका मिनिटात परत करता येणाऱ्या बदलापेक्षा डीबग करणे खूप कठीण आहे।