DNS عبر OpenVPN على البوابة: dnsmasq مع نطاق جدار الحماية

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

المستمع خدمة محلية ذات اتجاهين

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

انتهاء المهلة الذي يبلغ عنه العميل وانتهاء المهلة الذي يُرى على البوابة ليسا العطل نفسه.

اربط عنوان النفق، لا كل عنوان

نسخة dnsmasq مخصصة لهذه المهمة تحتاج إلى عنوان استماع صريح، ونمط ربط يتحمل ظهور النفق بعد البدء، ومصدر أعلى واحد واضح. هذه أصغر نسخة أستخدمها:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic يربط العناوين الفردية ويتعامل مع tun0 عندما يظهر لاحقًا، وهذا مهم على مضيف تُعاد فيه خدمة VPN. وإدراج loopback يبقي الأدوات المحلية عاملة دون إضافة مستمع عام. no-resolv يمنع البرنامج الخفي من وراثة المصادر الأعلى من تهيئة أداة الحل الخاصة بالمضيف، و no-hosts يمنع هذه النسخة من نشر ملف hosts الخاص بالبوابة. ولا يمنح أي من هذه الخيارات أي شخص إذنًا بالاستعلام من الخدمة.

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

اسمح بإدخال DNS، لا بمرور النفق

قواعد جدار الحماية التي تجعل هذا يعمل هي قواعد إدخال محلية مقيدة بواجهة النفق ومجموعة العملاء وعنوان البوابة والمنفذ 53. قاعدتان، واحدة لكل بروتوكول، تكفيان:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

يعمل DNS عبر TCP وكذلك UDP، لذا فإن قاعدة UDP وحدها تترك الأجوبة الكبيرة تفشل بطريقة تبدو متقطعة. هذه ليست ufw route أذونات، ولا يجوز أن تصبح سماحًا واسعًا على tun0. والترتيب لا يقل أهمية عن المحتوى: فالقاعدة الأسبق التي تُسقط كل الإدخال من tun0 تفوز مع ذلك، وإضافة سماح أسفل إسقاط نهائي لا تنشئ شيئًا.

إذا صار DNS البوابة جزءًا من التصميم الآن، فراجع تلك السياسة السابقة عن قصد وسجّل السبب.

نصف المصدر الأعلى مسار منفصل

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

لا تضف إخراج نفق غير مقيد لجعل الردود تعمل؛ فالردود المتتبعة لا تحتاج إليه.

ادفع الخيار، ثم تحقق من التسليم

يمكن للخادم أن يعلن أداة الحل للعملاء بخيار مدفوع. وهذا خيار، لا أمرًا يجب أن يطيعه نظام التشغيل:

push "dhcp-option DNS 10.90.0.1"

قد يحتاج عميل Linux سطري إلى تكامل أداة الحل في مدير اتصالاته، وقد يحتاج جهاز مُدار إلى تحديث ملف تعريف إدارته. تحقق من أداة الحل النشطة على العميل بعد الاتصال بدلًا من افتراض أن الدفع طُبّق. وعندما تحاول آليتان تعيين DNS معًا، تحصل على سباق يظهر كتحليل متذبذب.

الهدف مالك واحد لتهيئة أداة الحل على العميل، والدفع هو ذلك المالك عادةً فقط عندما توافق منصة العميل.

اختبر ما بنيته فعلًا

استعلم عن اسم خاص واحد مؤهل بالكامل واسم خارجي واحد مسموح به مباشرة ضد عنوان النفق، عبر UDP وTCP معًا. ثم كرر ذلك عبر مسار البحث العادي للتطبيق.

إذا نجحت الاستعلامات المباشرة وظل التطبيق يفشل، فالعطل في التسليم لا على الخادم:

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

اختم بالتأكد من أن مصدرًا خارج مسار VPN المعتمد لا يستطيع استخدام المستمع إطلاقًا. فالتحليل الناجح لا يصرح بالعنوان الذي أعاده، لذا أبقِ هذين السؤالين منفصلين.