يجيب AdGuard Home على عملاء WireGuard من عنوان LAN الخاص بك

النفق مفتوح، وجدار الحماية يسمح بالمنفذ 53، وAdGuard Home يعمل، ومع ذلك لا تزال الأسماء لا تُحل للعميل WireGuard. عادةً تصل الاستعلامات ويغادر الرد بشكل طبيعي، لذا تبدو عدادات الحزم على المُحلل صحيّة وتبدو الخدمة بريئة. ما يحدث خطأ هو عنوان المصدر في ذلك الرد: فهو يغادر من عنوان محلي لم يطلبه العميل، ويرفض محلل العميل المدمج الرد. قائمة واحدة في إعدادات AdGuard Home تحدد هذا، والافتراضي المعتاد يُسلم القرار للنواة.

يصل الاستعلام، ويغادر الجواب من مكان آخر

العميل الذي تم تكوينه باستخدام 10.6.0.1 كخادم حل يرسل استعلام UDP إلى 10.6.0.1 المنفذ 53. يعبر هذا الحزمة من النفق وتصل إلى المضيف، ويجيب عليها AdGuard Home. على الشبكة، مع ذلك، يكون الرد عبارة عن حزمة جديدة يتم اختيار عنوان مصدرها بواسطة نظام المضيف، وليس وفقًا لتوقع العميل.

عندما يكون محلل أسماء العميل هو مقبس متصل، وهو ما يستخدمه systemd-resolved و dnsmasq ومعظم محللات الأسماء المؤقتة، فإنه يقبل فقط الردود من العنوان الدقيق الذي أرسل إليه. يتم تجاهل رد مصدره 192.168.1.10 على استعلام تم إرساله إلى 10.6.0.1 قبل حدوث أي تحليل. يقوم محلل الأسماء بتسجيل إجابة ناجحة، ويسجل العميل نفاد المهلة، وكلاهما يقول الحقيقة.

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

كيف يختار النواة مصدر الرد

مقبس UDP مرتبط بـ0.0.0.0ليس لديه عنوان مصدر خاص به، لذا كل رد صادرة يستدعي البحث عن المسار للوجهة. ثم يأخذ النواة المصدر من ذلك المسار: العنوان المثبت بواسطة المسار، أو العنوان الرئيسي للواجهة الصادرة. لا يتم تذكر أي شيء عن عنوان الوجهة للاستعلام.

على جهاز يحتوي على واجهة واحدة، يكون هذا غير مرئي، لأنه لا يوجد سوى إجابة واحدة محتملة. على جهاز يحتوي على عنوان شبكة محلية، وعنوان WireGuard وعنوان إدارة، فإن هناك عدة إجابات محتملة، والفائز يعتمد على جدول التوجيه في تلك اللحظة. إضافة مسار إضافي، أو عنوان ثانٍ على نفس الواجهة، أو إعادة توجيه NAT أمام المحلل، أو تشغيل AdGuard في حاوية مع مساحة أسماء خاصة بها، يمكن أن تختلف المصدر المختار عن المصدر الذي استعلم عنه العميل.

ss -lunp | grep :53يُظهر اللعبة التي أنت فيها. مستمع على0.0.0.0:53هو حالة البدل؛ مستمع على10.6.0.1:53لقد قامت بالفعل بتثبيت الإجابة. قراءة المقبس أسرع من قراءة YAML، وهي تعكس ما يتم تشغيله فعليًا بدلاً من ما تم حفظه آخر مرة.

ما الذي يتحكم فيه bind_hosts فعليًا

أدغارد هومdns.bind_hostsهي قائمة العناوين المحلية التي يستخدمها مستمع DNS. الإعداد الافتراضي المرفق هو الرمز البريدي العام، مما يعني القبول على كل عنوان محلي وترك النواة لتحديد المصدر لكل رد. استبدال الرمز البريدي العام بالعنوان الذي يستعلم عنه العملاء يغير المقبس، ومعه عنوان المصدر في كل إجابة.

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

ملف YAML بسيط، والعنوان الموجود فيه هو الذي تم إخبار عملاء النفق باستخدامه، وليس العنوان الأساسي للمضيف:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

لماذا تختلف تثبيتان لنفس المحلل

المدار بواسطة الإضافة، في هذا السياق، يعني أن المحلل تم تثبيته ويتم الإشراف عليه بواسطة حزمة أخرى: حزمة برمجيات جهاز التوجيه، أو حزمة NAS، أو ملحق الأتمتة المنزلية. عادةً ما تُرسل تلك الحزمة نسختها الخاصة من YAML الخاص بـ AdGuard Home وتعيد تشغيل العملية وفق جدولها الخاص، بينما المثيل المستقل هو الثنائي أو الحاوية المقدم من البائع التي تقوم بتكوينها بنفسك. في كلتا الحالتين، أنت تنظر إلى عمليتين مستقلتين مع ملفات تكوين منفصلة وخيارات ربط منفصلة، حتى عندما يقرأ كلاهما نفس قائمة المصادر والمصادر المفلترة نفسها. يمكن لإحدى العمليات ربط عنوان النفق المحدد بينما الأخرى ترث العامل الجامح، وتبدو واجهة الويب متطابقة من كلا الجانبين.

لهذا السبب، "المحلل نفسه كان يعمل قبل النقل" لا يثبت شيئًا عن الربط الحالي. تحقق من المقبس، ثم تحقق من ملف التكوين الذي قام العملية الجارية بتحميله فعليًا. النسخة القديمة في دليل آخر هي سبب شائع لظهور التعديل وكأنه لم يؤثر.

ثبتها، ثم اختبرها من جانب النفق

تغييرbind_hostsإلى عنوان النفق، أعد تشغيل الخدمة، وتأكد من أن المقبس قد انتقل:ss -lunp | grep :53يجب أن يظهر الآن10.6.0.1:53ولا يوجد إدخال للجذر العام. إذا ظل يظهر0.0.0.0,العملية الجارية لا تقرأ الملف الذي قمت بتحريره.

ثم الاختبار من العميل، لأن هذا هو الجانب الوحيد الذي يهم. استعلام معdig @10.6.0.1 example.comالتمارين التي يمارسها المستخدم، ولقطة على المضيف معtcpdump -ni wg0 udp port 53يعرض عنوان المصدر للرد على الشبكة. قارن بينه وبين العنوان الموجود في إعداد محلل العميل؛ عندما يكونان متساويين، يتوقف الغموض حول انتهاء المهلة.

ip route get 10.6.0.2يشرح أي غرابة متبقية، لأنه يطبع الواجهة والمصدر الذي يستخدمه المضيف مرة أخرى إلى العميل. إذا كان هذا الإخراج يسمي واجهة الشبكة المحلية، فإن تغيير binding ليس هو الإصلاح الكامل وجدول التوجيه هو الشيء التالي الذي يجب قراءته.

ما لا يمكن أن يصلحه إعداد binding

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

كما أنه لا يغيرأي السيرفر العلوي يمرره المحلّل، سواء رفضت حماية إعادة الربط إجابة خاصة لاسم خاص، أو كيف يطبق العميل نطاقات البحث الخاصة به. هذه هي عناصر تحكم منفصلة. غير عنوان binding عندما يكون مصدر الرد خاطئًا، وغير شيئًا آخر عندما لا يكون كذلك.