كيفية إعداد تجاوزات DNS المحلية لوكلاء عكسيين متعددين

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

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

اربط الأسماء بحدود الوكلاء

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

تجنب منح الاسم نفسه سجلّي A خاصين، إلا إذا كان كلا الوكيلين نشطًا عمدًا ومكوّنين بالطريقة نفسها. يعيد DNS العناوين لا حالة الخدمة، لذلك قد ترسل سجلات round-robin العشوائية نصف العملاء إلى وكيل يفتقر إلى المسار أو الشهادة.

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

ضع التجاوزات في المحلل الذي يستخدمه العملاء فعليًا

أنشئ المنطقة المحلية أو تجاوزات المضيف على خدمة DNS التي يعلنها DHCP لتلك الشبكة. وجّه كل اسم تطبيق إلى عنوان LAN للوكيل المسؤول عنه، لا إلى حاوية التطبيق ولا تلقائيًا إلى عنوان WAN العام.

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

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

طابق مسارات الوكيل وTLS وعناوين URL للتطبيق

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

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

بالنسبة إلى التطبيقات المستضافة ضمن مسار، حافظ على توافق مسار الوكيل مع عنوان URL الأساسي للتطبيق. ويوضح دليل ZimaSpace حول إزالة تعرّض Jellyfin بأمان أيضًا سبب ضرورة تتبّع DNS ومسارات الوكيل وإعادة التوجيه وقوائم التحكم بالوصول معًا.

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

تحقق من كل شبكة وحدد إجراء التراجع

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

افتح التطبيق من شبكة LAN موثوقة، أو شبكة VLAN للضيوف أو الوسائط، أو VPN حسب الاقتضاء. سجّل العنوان الذي جرى حله، واسم الشهادة، وحالة HTTP، وإعادة التوجيه النهائية؛ إذ تحدد هذه الملاحظات ما إذا كان العطل متعلقًا بـDNS أو TLS أو توجيه الوكيل أو التطبيق.

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