أستكشاف أخطاء الوصول الخاص وإصلاحها مع ZTNA CLAP/BAP عبر موصلات الموارد بسبب فشل DNS

خيارات التنزيل

  • PDF     (247.4 KB)
    عرض باستخدام Adobe Reader على مجموعة متنوعة من الأجهزة
تم التحديث:١٠ سبتمبر ٢٠٢٦
معرّف المستند:226324

لغة خالية من التحيز

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

حول هذه الترجمة

ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).

مسألة

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

وتشمل الأعراض المحددة ما يلي:

  • تم تسجيل أخطاء فشل DNS لموصل مورد الإنتاج

  • حالات فشل الاتصال بسبب ضرب قاعدة الحظر الافتراضية في تقرير البحث عن النشاط

  • عدم القدرة على التحقق من صحة وظيفة موصل موارد الإنتاج

  • التأثير المحتمل للوصول إلى الموارد الخاصة عبر ZTNA CLP باستخدام Resource Connector

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

البيئة

  • التقنية: دعم الحلول (SSPT - العقد مطلوب)

  • التقنية الفرعية: الوصول الآمن - الوصول بدون ثقة (ZTNA، الوضع، مستند إلى العميل، التسجيل، المورد الخاص)

  • مجموعة المنتج: الوصول الآمن، عدم الثقة/ZTNA، موصل الموارد

  • التطبيق/الخادم الخاص الهدف: يمكن الوصول إلى خادم Ubuntu على منفذ TCP 8443

  • مكونات الشبكة: موصلات الموارد في كل من بيئات التطوير والمنتج

قرار

يركز نهج أستكشاف الأخطاء وإصلاحها على إختلافات تكوين DNS بين موصلات موارد التطوير والإنتاج. الرجاء ملاحظة أن موصل موارد التطوير يعمل في السيناريو - يمكن الوصول إلى الموارد الخاصة بنجاح.
موصل مورد الإنتاج لا يعمل، ولا يمكن الوصول إلى PR، كما أن إدخال خطأ فشل DNS في RC > إتصالات الشبكة > موصل الموارد > فشل DNS.

اتبع هذه الخطوات المنهجية لتحديد وحل مسائل حل نظام أسماء المجالات.

الخطوة 1: مقارنة تكوين DNS بين البيئات

إجراء مقارنة شاملة لإعدادات DNS بين موصلات موارد DEV و PROD:

1.- توثيق تكوينات خادم DNS في كل من موصلات موارد التطوير والإنتاج.

2.- تحديد ما إذا كان موصل التطوير يستخدم إعدادات DNS الافتراضية أو خوادم DNS البديلة.

3.- مقارنة تكوين DNS لموصل الإنتاج مع إعداد تطوير العمل.

4.- لاحظ أي إختلافات في طرق تحليل DNS أو فترات المهلة أو التكوينات الاحتياطية.

الخطوة 2: إختبار تكوين خادم DNS البديل

إذا كان موصل مورد الإنتاج يستخدم إعدادات DNS الافتراضية وكان موصل التطوير يستخدم خوادم DNS بديلة، أو العكس:

  • قم بتكوين موصل مورد الإنتاج لاستخدام نفس إعدادات خادم DNS كموصل تطوير العمل

  • بدلا من ذلك، حدد خوادم DNS البديلة في تكوين موصل مورد الإنتاج

  • إختبار اتصال الموارد الخاصة بعد كل تغيير في تكوين DNS

  • مراقبة سجلات الموصل لنجاح تحليل DNS أو إستمرار الأخطاء عند إستخدام التشخيصات، Tcpdump إلى IP وجهة PR

note-icon

ملاحظة: يمكن لكلا موصلي الموارد حل اسم المجال المؤهل بالكامل (FQDN) الخاص ب PR عند إستخدام DNS الافتراضي الذي تم تكوينه على RC، ولكنه لا يتطابق مع DNS الداخلي الذي تم تكوينه على تكوين الموارد الخاصة ل RC غير العامل أو الإنتاج.

الخطوة 3: التحقق من دقة DNS والاتصال

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

بعد تنفيذ تغييرات تكوين DNS:

1.- التحقق من أن حل DNS يعمل بشكل صحيح من موصل مورد الإنتاج

2.- تأكيد أن المورد الخاص لم يعد يصل إلى قاعدة الحظر الافتراضية

3.- إختبار الاتصال الشامل من خلال موصل الإنتاج

السبب

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

ومع ذلك، تم تكوين "موصل موارد الإنتاج" لاستخدام DNS الافتراضي، والذي يختلف عن خوادم DNS الداخلية المذكورة في تكوين PR.

تم تحديث "موصل مورد الإنتاج" لاستخدام خوادم DNS الداخلية لمطابقة تكوين PR لحل المشكلة.

المحتوى ذي الصلة

محفوظات المراجعة

المراجعة تاريخ النشر التعليقات
1.0
10-Sep-2026
الإصدار الأولي
TAC Authored

تمت المساهمة بواسطة مهندسو Cisco

  • فايشنافي تشانذو راجندران
    مهندس إستشاري تقني

هل كان هذا المستند مفيدًا؟

Feedbackالتعليقات

اتصل بنا

ينطبق هذا المستند على هذه المنتجات