توجيه عملاء OpenVPN إلى مُحلِّل Pi-hole على مضيف آخر

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

ما يفعله خيار DNS المدفوع وما لا يفعله

يعلن الخادم عن مُحلِّل بالتوجيه أدناه، بافتراض أن 192.168.50.53 هو مضيف Pi-hole. يتلقى العميل الخيار و، بحسب منصته وتكامل المُحلِّل ، يطبّقه على واجهة النفق أو يتجاهله لصالح وكيل محلي. سطر المسار لا يقل أهمية عن سطر DNS، لأن مُحلِّلًا لا يصل إليه العميل ليس مُحلِّلًا على الإطلاق. لا شيء من هذا مرئي من جانب الخادم.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

تلقّي خيار ليس مثل استخدامه. قد يقبل عميل Linux لديه مدير مُحلِّل الخادم المدفوع ويرسل إليه نطاقات معينة فقط؛ وقد يستبدل عميل يدير DNS بنفسه الإعداد بالكامل. المسارات المدفوعة مقيّدة أيضًا على بعض المنصات، ما يترك المُحلِّل غير قابل للوصول رغم قبول الخيار. افحص على العميل أي خادم يجيب، لا على الخادم ما أُرسل.

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

مسار العودة من Pi-hole إلى التجمع

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

أعطِ موجه LAN مسارًا ثابتًا للتجمع مع بوابة OpenVPN كقفزة تالية، أو ترجم المصدر على البوابة قبل إعادة التوجيه إلى Pi-hole. الأول يبقي عناوين كل عميل مرئية في سجل استعلامات Pi-hole. الثاني يزيل شرط مسار العودة لكنه يجعل كل استعلام يبدو قادمًا من البوابة. لا أحد منهما خطأ؛ إنهما يجيبان عن أسئلة مختلفة.

إذا كانت التقارير أو السياسة لكل عميل مهمة، فالمسار الثابت هو المقايضة الأفضل. إذا كان LAN يديره شخص آخر ولا يتوفر مسار، فالترجمة هي الخيار العملي، مع تسجيل فقدان هوية العميل. سجّل أي الخيارين اخترت، لأن كل سؤال لاحق عن السجلات يعتمد عليه.

وضع استماع Pi-hole للعملاء الموجّهين

قائمة سلوك استماع الواجهات المنسدلة في صفحة الإعدادات ضمن DNS تحدد المصادر التي يرد عليها Pi-hole. الخيار الأكثر صرامة لا يقبل إلا العملاء على الشبكات المتصلة مباشرة؛ والخيار الذي يسمح بالأجهزة على مسافة قفزة واحدة على الأكثر يوسّع ذلك إلى الشبكات الفرعية خلف موجه مجاور، وهذا بالضبط شكل عميل VPN موجّه. تصل الحزمة فعلًا إلى واجهة LAN، لكن عنوان مصدرها ينتمي إلى شبكة فرعية أخرى. هذا رفض سياسة وليس فشل توجيه، والفرق مهم عند قراءة السجلات.

دليل Pi-hole عن الاستماع يفصل المصادر المتصلة محليًا عن الأصول الموجّهة، وواجهة الوصول ليست المعيار. اختر وضعًا يسمح بتجمع VPN دون السماح بالإنترنت كله، ثم اقرنه بقاعدة جدار حماية تقبل DNS من التجمع فقط.

فتح الاستعلام العودي لكل الأصول لجعل الاستعلام الأول ينجح هو الإصلاح الخاطئ. يحوّل مُحلِّلًا خاصًا إلى مفتوح، والإصلاح هو إذن محدود النطاق لا إذن عالمي.

طابق الرد مع سجل الاستعلامات

اسأل العميل، ثم افحص الخادم وقارن الاثنين. على عميل systemd-resolved تُبلغ الأوامر أدناه أي مُحلِّل أنتج ردًا وأي خوادم مُهيأة لكل رابط. استخدم اسمًا يعرفه Pi-hole فقط، لأن الاستعلام المباشر على عنوان Pi-hole يثبت الوصول لا التهيئة.

resolvectl query intranet.example.lan
resolvectl dns

الرد المتوقع يسمّي 192.168.50.53 خادمًا ويعيد عنوانًا لا يعرفه إلا ذلك المُحلِّل. ثم انظر إلى عرض Pi-hole نفسه: pihole -t يتابع سجل الاستعلامات مباشرة، وكل سطر يحمل عنوان المصدر. إذا كان المصدر عنوان النفق للعميل، فمسار التجمع سليم. وإذا كان عنوان LAN للبوابة، فالترجمة المصدرية جارية ولن يظهر عنوان العميل نفسه أبدًا.

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

افحص قاعدة إعادة التوجيه في البوابة

على البوابة أن تعيد توجيه حزم DNS الخاصة بالعميل نحو Pi-hole، وقاعدة ذلك تستحق القراءة لا الافتراض. الأوامر أدناه تسرد القواعد التي تمس المنفذ 53 مع العدادات، على مضيف nftables وعلى مضيف iptables. قاعدة موجودة لكنها تُظهر صفر مطابقات هي إشارة إلى أن الحركة تُسقط قبل ترجمتها.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

اقرأ العدادات، لا القواعد فقط. قاعدة لا تطابق أبدًا تعني أن الحزمة تغادر عبر واجهة أخرى، أو أن العميل لم يرسلها أصلًا. قاعدة تطابق في كل استعلام تعني أن إعادة التوجيه تعمل وأن المشكلة أبعد على المسار.

أيًا كانت الأداة التي يستخدمها المضيف، أبقِ الفحص ضيقًا: التجمع كمصدر، والمنفذ 53 كوجهة، وPi-hole كهدف وحيد مسموح. قاعدة إعادة توجيه واسعة تسمح أيضًا بالمنفذ 80 هي مشكلة أخرى تنتظر الحدوث.