كيفية استكشاف أخطاء تطبيق بعيد يعمل عبر عنوان IP ولا يعمل عبر النطاق

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

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

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

تأكد من أن اختبار IP يصل إلى الخدمة المقصودة

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

يوضح دليل إعداد وكيل عكسي في مختبر منزلي أن الوكيل يمكنه استضافة عدة تطبيقات على عنوان واحد لأنه يفحص ترويسة Host المطلوبة قبل اختيار الخدمة المصدر.

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

قارن DNS العام بعنوان IP العامل

استعلم عن النطاق عبر خادم أسماء موثوق ومن خلال محلل تكراري خارجي واحد على الأقل. سجّل كل إجابات A وAAAA وقيمة TTL وما إذا كان CNAME يشير إلى اسم مضيف آخر.

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

إذا اختلف سجل A عن عنوان IP العامل، فصحّح السجل أو محدّث DDNS. وإذا كان A صحيحًا لكن AAAA يشير إلى مسار IPv6 يتعذر الوصول إليه، فاختبر كل عائلة عناوين على حدة وأزل السجل المعطوب أو أصلحه.

اتصل بعنوان IP العامل مع الحفاظ على النطاق

استخدم عميلًا يمكنه الاتصال بعنوان IP العامل المعروف مع إرسال النطاق بوصفه ترويسة HTTP Host واسم خادم TLS. يغيّر ذلك الوجهة من دون التخلي عن الهوية التي يتوقعها الوكيل والشهادة.

يوضح Server Fault أن الوكيل العكسي لـ HTTP يمكنه استخدام ترويسة Host لاختيار مسار بالطريقة نفسها التي تعمل بها المضيفات الافتراضية المعتمدة على الاسم.

إذا نجح الطلب مع الحفاظ على النطاق، فإن DNS هو طبقة الخلل. وإذا وصل الطلب إلى الوكيل لكنه أعاد الموقع الخطأ أو الخطأ 404، فتحقق من مطابقة المضيف الافتراضي وأولوية المسارات؛ أما إذا فشل TLS قبل HTTP، فتحقق من SNI واختيار الشهادة.

-15% OFF

تحقق من SNI في TLS وهوية الشهادة

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

ينقل SNI اسم المضيف في رسالة TLS ClientHello قبل طلب HTTP المشفّر، مما يسمح للوكيل باختيار المضيف الافتراضي الآمن. لذلك قد يفتقر طلب يعتمد على عنوان IP فقط إلى اسم المضيف المستخدم أثناء اختيار TLS، حتى عند وصوله إلى المستمع نفسه.

أصلح شهادة النطاق ومسار SNI بدلًا من توقّع وجود شهادة لعنوان IP خاص أو ديناميكي. وإذا كانت هناك شبكة CDN أو وكيل TCP أمام الخادم، فتأكد من أنه يمرر SNI لاسم المضيف المقصود أو ينهيه.

تحقق من أن DNS الداخلي والخارجي لا يرسلان عبر مسارات مختلفة

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

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

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

تحقق من عناوين URL الأساسية وعمليات إعادة التوجيه قبل إعلان إصلاح DNS

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

تتناول مقالة ZimaSpace حول ما إذا كان DNS المنقسم يمكنه إصلاح فشل لا يحدث إلا داخل المنزل الحالة القريبة التي يكون فيها اسم المضيف صحيحًا، لكن المسار يختلف حسب الموقع.

لا تُحل المشكلة إلا عندما يعيد DNS الموثوق العنوان المقصود، ويحدد النطاق الشهادة ومسار الوكيل الصحيحين، وتحافظ عمليات إعادة التوجيه على اسم المضيف العام، وينجح سير العمل الكامل عن بُعد من دون استبدال النطاق بعنوان IP.

الدعم والنصائح

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.