كيفية إعداد DNS بنطاق منقسم للوصول إلى التطبيقات داخليًا وعن بُعد

إيفا وونغ

IceWhale author

إيفا وونغ هي كاتبة تقنية و ومهندسة هاوية في ZimaSpace. مهووسة بالتكنولوجيا مدى الحياة ولديها شغف بالمختبرات المنزلية والبرمجيات مفتوحة المصدر، تتخصص في تبسيط المفاهيم التقنية المعقدة إلى أدلة عملية وسهلة الفهم. تؤمن إيفا بأن الاستضافة الذاتية يجب أن تكون ممتعة وليست مخيفة. من خلال دروسها، تمكّن المجتمع من تبسيط إعدادات الأجهزة، بدءًا من بناء أول نظام تخزين شبكي NAS وحتى إتقان حاويات Docker.

How to Set Up Split-Horizon DNS for Internal and Remote App Access - Zima Store Online

استخدم اسم مضيف التطبيق نفسه في كل مكان، لكن أعد عنوان وكيل خاص للعملاء الداخليين الموثوقين وعملاء VPN، ونقطة النهاية العامة أو نقطة نهاية النفق للعملاء الخارجيين. أبقِ اسم TLS متطابقًا في كلا المسارين.

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

حدّد العرضين الداخلي والخارجي

اختر اسم نطاق مؤهلًا بالكامل (FQDN) واحدًا لكل تطبيق. في DNS العام، وجّه الاسم إلى الوكيل أو النفق أو البوابة التي يمكن الوصول إليها خارجيًا؛ وفي DNS الداخلي، تجاوز ذلك ووجّهه إلى العنوان الخاص للوكيل المحلي.

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

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

اجعل اختيار محلل الأسماء حتميًا

أعلن عن محلل الأسماء الداخلي عبر DHCP ومن خلال ملف تعريف VPN. استعلم عنه صراحةً أولًا، ثم استعلم عبر نظام التشغيل لاكتشاف أي تجاوز لذاكرة التخزين المؤقت المحلية أو لـ DNS المشفّر.

قد تنتج ذاكرات التخزين المؤقت لمحللات الأسماء ومكتبات DNS المختلفة نتائج مفاجئة؛ يشرح هذا الدليل حول أسباب فشل DNS الشائعة سبب عدم ظهور التغيير المعتمد فورًا لدى العميل.

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

نسّق سلوك الوكيل والشهادة والتطبيق

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

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

إذا كان التطبيق يستخدم مسارًا فرعيًا، فأبقِ عنوان URL الأساسي ومسار الوكيل متزامنين. تساعد قائمة التحقق من ZimaSpace الخاصة بـ ترقيات حاوية Jellyfin في الحفاظ على إعدادات الوكيل والربط وعنوان URL قبل إجراء أي تغيير.

Featured

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

ZimaCube2

اختبر الانتقال بين الوصول الداخلي وعن بُعد

على شبكة Wi-Fi، سجّل خادم DNS والعنوان المُعاد والشهادة ونتيجة التطبيق. كرر الاختبار عبر شبكة الهاتف المحمول مع تعطيل Wi-Fi؛ يجب أن يتغير العنوان بينما يظل اسم المضيف وهوية الشهادة كما هما.

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

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