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 र रिजोल्भर मानहरू राख्नुहोस्; बेलुकाको खानामा घरको इन्टरनेट तोड्ने परिवर्तन एक मिनेटमा फर्काउन सकिने परिवर्तनभन्दा धेरै गाह्रो हुन्छ।