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 और रिज़ॉल्वर मान रखें; रात के खाने के समय घर का इंटरनेट तोड़ देने वाले बदलाव को डिबग करना उस बदलाव से कहीं कठिन है जिसे आप एक मिनट में वापस ला सकते हैं।