لا يحجب Pi-hole الإعلانات بعد اتصال VPN: خمسة فحوص

لا تزال الإعلانات تظهر على أحد العملاء، ويعلن Pi-hole أنه سليم، والنفق قائم، لذا فإن الغريزة هي توجيه حركة ذلك العميل عبر Pi. هذا منعطف خاطئ. الترشيح يحتاج إلى الأسئلة لا إلى الحزم، والعميل الذي تذهب استعلاماته إلى محلل مزود الخدمة يبقى غير مرشح مهما كان مسار حركته. اتبع هذه القائمة بالترتيب وتوقف عند أول خطوة تفشل، لأن خطوة لاحقة لا يمكن أن تخبرك بشيء بينما خطوة سابقة معطلة.

1. اقرأ المحلل الذي يستخدمه العميل فعلا

اسأل العميل لا الموجه. على Linux يطبع resolvectl status خوادم DNS لكل وصلة والوصلة التي تفوز؛ أما /etc/resolv.conf بمفرده فهو عادة وكيل ثابت يشير إلى 127.0.0.53. على Windows يسرد ipconfig /all الخوادم المقدمة عبر DHCP لكل محول، وعلى macOS يعرض scutil --dns الشيء نفسه حسب النطاق. إذا لم يكن الجواب عنوان Pi-hole، فلديك مشكلة إسناد والخطوة 2 هي مكانها.

هناك أمران يبطلان محلل النظام حتى عندما يكون مضبوطا بشكل صحيح. المتصفحات التي لديها DNS آمن خاص بها (خيار “Use secure DNS” في Chrome، وnetwork.trr.mode في Firefox) ترسل الاستعلامات عبر 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؛ وعلى واجهة ويب الموجه هو حقل DNS في قسم DHCP للشبكة المحلية. على العملاء التجديد قبل أن يروه. الجهاز الذي يعمل منذ أيام لا يزال يحتفظ بالإيجار القديم، والجهاز الذي كتب فيه المحلل يدويا يحتفظ به إلى الأبد. جدد على عميل اختبار بدلا من افتراض الانتشار.

IPv6 هو النصف الذي ينسى. يمكن لإعلانات الموجه أن تحمل خادم DNS خاصا بها (RDNSS)، وعلى OpenWrt هذا هو خيار ra_dns في odhcpd؛ والعميل الذي يفضل IPv6 يستخدم ذلك الخادم بينما يبقى خيار DHCPv4 الذي ضبطته للتو غير مستخدم. إن لم تكن مستعدا لخدمة DNS عبر IPv6، فامسح إعلان DNS فقط: ra_dns في odhcpd، أو خيار RDNSS في أي شيء يجيب إعلانات الموجه. إيقاف الإعلان كله يزيل أيضا عنونة 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 مدفوع إعداد الشبكة المحلية لحظة قيام النفق: خوادم OpenVPN تدفع dhcp-option DNS، وملفات WireGuard تحمل إدخال DNS خاصا بها. اقرأ المحلل الفعلي للموجه والنفق قائم، لا قبله، وتجاهل ما تدعيه صفحة الشبكة المحلية.

العطل الآخر هو قابلية الوصول لا الاستبدال. إذا كانت البادئات المسموح بها للنفق تشمل شبكتك الفرعية المحلية، فللموجه مسار يرسل استعلامات 192.168.1.53 إلى النفق، ولا يوجد للطرف الآخر مسار عائد: تنتهي مهلة الاستعلامات رغم أن النفق سليم. ويحدث العكس عندما يكون Pi-hole على شبكة فرعية لا يحملها النفق. قارن العنوان بالبادئات المسموح بها للنفق وجدول مسارات الموجه قبل أن تلمس DNS مرة أخرى.

اختر إصلاحا واحدا لا كليهما. إما أن تبقي النفق بعيدا عن DNS، باستخدام pull-filter ignore “dhcp-option DNS” على OpenVPN وعدم وضع بادئة LAN في AllowedIPs على WireGuard، أو أن تقبل المحلل المدفوع وتتخلى عن الترشيح المحلي للعملاء خلف ذلك الموجه. أيا كان اختيارك، اكتبه بجوار الملف الشخصي، لأن الشخص التالي الذي سيحرره سيعكس القرار عن غير قصد.

5. أعد الاختبار بعد إعادة الاتصال

استعلم من عميل، وتأكد من ظهور ذلك العميل في سجل Pi-hole، ثم حلل نطاقا يجب حجبه وتحقق من أنك تحصل على جواب الحجب بدلا من الجواب الحقيقي. أعد توصيل النفق وشغل الاستعلامين نفسهما، لأن إعداد محلل لا يصمد إلا حتى إعادة الاتصال التالية هو النتيجة المعتادة لإصلاح طبق في الطبقة الخاطئة.

اترك مسار محلل ثانويا لا يعتمد على النفق، حتى يتحول انقطاع Pi-hole إلى تصفح غير مرشح بدلا من لا تصفح على الإطلاق. أبق قيم DHCP والمحلل السابقة حتى ينجح الاختبار مرتين؛ فتغيير يقطع إنترنت الأسرة على العشاء أصعب بكثير في التشخيص من تغيير يمكنك التراجع عنه في دقيقة.