استكشاف أخطاء الوصول إلى الموارد الداخلية وإصلاحها

نظرة عامة

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

الأعراض

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

  • لا يمكن حل اسم نطاق السيرفر الداخلي
  • السيرفر الداخلي لا يمكن الوصول إليه
  • عدم تطابق قاعدة جدار الحماية WAN
  • لا يستطيع عملاء SDP الوصول إلى الموارد الداخلية
  • (المورد RPF لإعادة توجيه المنفذ البعيد لا يمكن الوصول إليه
  • مضيف المراقبة LAN غير قابل للوصول

الأسباب المحتملة

  • مشاكل التوجيه
  • سوء تكوين إعادة توجيه DNS
  • سوء تكوين جدار الحماية WAN
  • تداخل مع شبكة عميل SDP
  • تدخل الأمان
  • مشاكل الاتصال مع مضيف الوجهة

التقييم الأولي

ملاحظة

ملاحظة: تأكد من وجود قاعدة جدار حماية WAN (حتى لو كانت مؤقتة لأغراض استكشاف الأخطاء) مع تمكين تتبع الأحداث.

لمشاكل المتعلقة بالوصول إلى السيرفرات الداخلية عبر المتصفح، انظر استكشاف مشاكل وصول المتصفح

راجع أحداث جدار الحماية WAN و IPS ومكافحة البرمجيات الخبيثة عن طريق اختيار الإعداد المسبق المناسب في CMA. تعيين الفلاتر لتضييق حركة المرور المثيرة للاهتمام والتحقق مما إذا كان التدفق قد تم حجبه بواسطة جدار حماية WAN أو محركات IPS/AM. حقل القاعدة سيظهر القاعدة المعنية التي تتطابق مع حركة المرور.

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

استكشاف المشكلة

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

التحقق من سجلات مسارات التدقيق

تحقق من مسار التدقيق لأي سجلات معدلة قد أثرت على الوصول إلى الموارد الداخلية. يشمل ذلك قواعد جدار الحماية WAN، إعدادات AM/IPS، وفحص TLS.

استكشاف حلول مشكلات حل اسم نطاق السيرفر

التحقق من حل DNS

إذا كان من المفترض الوصول إلى المورد الداخلي باستخدام اسم النطاق الخاص به، تأكد مما إذا كان يمكن حل اسم نطاق السيرفر الداخلي باستخدام أوامر nslookup أو dig من سطر الأوامر.

يمكن أن يكون هناك سيناران لحل DNS الداخلي في حسابك:

  • إذا تم استخدام عنوان IP لخادم DNS خاص في المؤسسة، تحقق مما إذا كان يمكن للمستخدمين المتأثرين الوصول إلى خادم DNS داخليًا. إذا لم يكن كذلك، استكشاف الأخطاء المتعلقة بالاتصال بخادم DNS، على نحو مشابه لـ استكشاف مشاكل الوصول إلى السيرفر الداخلي
  • إذا كانت سيرفر DNS كاتو الافتراضي 10.254.254.1، سيرفر DNS محدد الحساب، أو DNS عام معروف (8.8.8.8، 1.1.1.1، أو 9.9.9.9) مستخدمة في الحساب، استكشاف إعادة توجيه DNS في الخطوة التالية.

التحقق من إعادة توجيه DNS

يجب أن تكون تدفقات المرور التي تعتمد على أسماء النطاقات الداخلية (مثل pc1.domain.net) قد تم تكوينها بشكل صحيح في إعادة توجيه DNS في CMA. من الضروري أيضًا أن تقوم كاتو باعتراض تدفقات DNS لتتمكن من حل أسماء النطاقات بشكل صحيح.

يمكن لإعادة توجيه DNS العمل فقط إذا كانت استفسارات DNS موجهة إلى سيرفرات DNS محددة كما هو موضح في حل مشاكل إعادة توجيه DNS.

استكشاف الوصول إلى السيرفر الداخلي غير القابل للوصول

التحقق من جدول التوجيه الخاص بكاتو

يمكن استخدام جدول التوجيه للتحقق من توفر المسار، المقاييس، وأكثر:

  • ابحث عن عنوان IP للمورد في سلسلة البحث وتأكد من أن هناك مسار مطابق موجود عبر الموقع الصحيح.
  • إذا لم يتم العثور على مسار، فهذا يعني أن كاتو غير مدرك لهذا المسار، وبالتالي لا يمكن توجيهه إلى هذه الوجهة. لحل هذه المشكلة، انظر حل مشاكل التوجيه
  • إذا كانت هناك مسارات إلى نفس الوجهة، تحقق من أن نطاقات BGP الديناميكية لا تتداخل مع مسارات ثابتة أخرى. يفضل المسارات ذات المقاييس الأقل.
  • قد تعلن BGP أيضًا عن مسارات زائدة من مواقع مختلفة. يفضل المسار ذو المقاييس الأقل بما في ذلك الوزن، طول AS، أو MED. انظر فهم حقول جدول التوجيه.
  • لحل مشاكل المقاييس، انظر حل مشاكل التوجيه

التحقق من التوجيه المستند إلى السياسة IPSec

إذا كان المورد الداخلي يمكن الوصول إليه عبر IPSec، تأكد من أن النطاقات الصحيحة محددة في أقسام IPSec وNetworks في الموقع كما هو موضح في IPSEC Troubleshooting Playbook.

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

التحقق من حيوية المورد الداخلي

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

قد تكون المضيفون التي لم يتم رؤيتها مؤخرًا من قبل الموقع مغلقة أو غير متصلة بالشبكة.

قم بتنفيذ التقاط الحزم من واجهة الويب وتحديد أية مشكلات محتملة داخل الشبكة.

التحقق من تدفقات TLS

إذا كانت حركة المرور المثيرة للاهتمام هي TLS وقد قمت بالتحقق من الخطوات السابقة للسماح بحركة المرور. تحقق مما إذا كانت تدفقات حركة المرور تخضع لفحص TLS بواسطة كاتو. يمكن العثور على ذلك في قاعدة FW مع تعيين حقل فحص TLS على 1.

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

استكشاف عدم تطابق قاعدة جدار الحماية WAN

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

التحقق من التطبيق المخصص

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

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

التحقق من التطبيق/الخدمة المدمجة

إذا كانت حركة المرور المثيرة متوقعة لمطابقة تطبيق أو خدمة مدمجة وحركة المرور تطابق القاعدة الخاطئة لجدار الحماية، تحقق من التالي:

  • ما هي التطبيقات أو الخدمات التي تم تكوينها في قاعدة جدار الحماية 'الخاطئة'.
  • ما إذا كان أي من هذه التطبيقات/الخدمات مدرج في حقل التطبيقات ذات الصلة من حدث FW.

عملية تحديد التطبيق/الخدمة هي عملية متعددة الخطوات تبدأ بتحديد البروتوكول ثم تحديد جميع التطبيقات القابلة للمطابقة التي تم تضمينها في حقل التطبيقات ذات الصلة. أي تطبيق 'ذو صلة' تم تحديده في التدفق بغض النظر عن القرار النهائي للتطبيق (حقل التطبيق) سيطابق قاعدة جدار الحماية.

في المثال أدناه، تطابق حركة مرور SMB القاعدة #1 بدلاً من القاعدة #2. وذلك لأن القاعدة #1 تتضمن خدمة TCP (المضمّنة في التطبيقات ذات الصلة) حتى وإن كانت التطبيق النهائية (حقل التطبيق) هي SMB.

لحل هذا السلوك المتوقع، راجع ترتيب قواعد جدار الحماية

التحقق من اسم النطاق المضبط

إذا احتوت قاعدة جدار الحماية على كائن نطاق أو FQDN، تحقق مما إذا كان حقل اسم النطاق في حدث FW. يجب أن يكون كائن النطاق/FQDN في قاعدة جدار الحماية مطابقًا لهذا الحقل.

ضع في اعتبارك أن الـFQDN هو تطابق كامل للنطاق المؤهل بالكامل. على سبيل المثال، FQDN example.com يطابق فقط example.com.

من ناحية أخرى، فإن النطاق هو نطاق من المستوى الأعلى (TLD) أو مستوى ثاني (SLD) الذي يتطابق مع جميع النطاقات الفرعية. على سبيل المثال، نطاق example.com يطابق www.example.com وhost.example.com.

يمكن أن تكون هناك حالات حيث لا يمكن لـكيتو تحديد اسم النطاق الصحيح من تدفقات HTTP، TLS، أو DNS. لحل هذه الأنواع من المشاكل، انظر حل مشاكل عدم تطابق اسم النطاق

استكشاف عميل SDP عدم الوصول إلى الموارد الداخلية

هذا القسم يعالج المشاكل الحصرية لعملاء SDP الذين لا يستطيعون الوصول إلى الموارد الداخلية.

التحقق من تداخل الشبكة الفرعية لشبكة المنزل للمستخدم

إذا كان عميل SDP لا يستطيع الاتصال بالموارد الداخلية، بما في ذلك تشغيل ping على السيرفر، تحقق مما إذا كان هناك تداخل في عنوان IP بين شبكة المنزل للمستخدم والموقع مع الموارد الداخلية. إذا كان هذا هو الحال، فإن جدول التوجيه للعميل سيشير إلى بطاقة NIC المحلية عند محاولة الاتصال بالخادم الداخلي الواقع خلف موقع كيتو البعيد، مما يؤدي إلى فشل الاتصال.

يمكن للمواقع البعيدة ذات النطاق IP 192.168.0.0/24، 192.168.1.0/24 أو 10.0.0.0/24 أن تتداخل بسهولة مع نطاق IP لأجهزة التوجيه اللاسلكية في المنزل، التي تستخدم غالبًا هذا النطاق كنطاق افتراضي لتوزيع DHCP.

لحل هذه المشكلة، اتبع الخطوات الموضحة في لا يمكن لعميل SDP الاتصال بالموارد WAN البعيدة.

مستخدمي نظام macOS وiOS لا يحلوا أسماء النطاقات الداخلية

كما هو موضح في macOS Ventura وiOS المستخدمون غير قادرين على الوصول إلى الموارد الداخلية عبر Cato، إذا لم يتمكن SDP Client من الاتصال بالموارد الداخلية باستخدام اسم النطاق الخاص به ولكنه قادر على الوصول إليه باستخدام عنوان IP الخاص به، فمن الممكن أن يكون توجيه DNS فاشلًا بسبب استخدام DoH (DNS فوق HTTPS) أو DoT (DNS عبر TLS) من قبل نقطة النهاية. Cato لا تدعم حاليًا DoH/DoT.

لحل هذه المشكلة، انظر حل مشاكل إعادة توجيه DNS. بدلاً من ذلك، يمكن تعريف سيرفر DNS كاتو (10.254.254.1) في CMA كسيرفر DNS الوحيد للنقطة الطرفية.

مستخدمو أندرويد لا يحلون أسماء النطاقات الداخلية

كما هو موضح في أجهزة Android غير قادرة على الوصول إلى الموارد الداخلية عبر Cato، إذا لم يتمكن SDP Client من الاتصال بالموارد الداخلية باستخدام اسم النطاق الخاص به ولكنه قادر على الوصول إليه باستخدام عنوان IP الخاص به، فمن الممكن أن يكون توجيه DNS فاشلًا بسبب استخدام DNS خاص تلقائي من قبل الجهاز (السلوك الافتراضي) الذي يفرض DoH/DoT لحل DNS. حاليًا، هذا غير مدعوم بواسطة كاتو.

لحل هذه المشكلة، انظر حل مشاكل إعادة توجيه DNS. بدلاً من ذلك، يمكن تعطيل DNS الخاص على الجهاز.

استكشاف الموارد الداخلية RPF

تحليل حدث RPF

مراجعة أحداث RPF من خلال تحديد الإعداد المسبق RPF في CMA. تأكد من توليد الحدث الذي يؤكد أن عنوان Cato الخارجي متاح. لاحظ أن عنوان IP الوجهة هو العنوان العام الخارجي المكوّن في قاعدة RPF.

تحليل حدث الحظر الجغرافي

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

التحقق من حيوية المورد الداخلي

تحقق من قيمة النشاط المعروف الأخير من صفحة المضيفين المعروفين على الموقع. انظر إظهار المضيفين المعروفين لموقع

المضيفين الذين لم يتم رؤيتهم مؤخرًا من قبل الموقع قد يكونوا مغلقين أو غير متصلين بالشبكة.

قم بتشغيل التقاط الحزم من واجهة المستخدم على الويب وحدد أي مشاكل محتملة داخل الشبكة المحلية.

استكشاف أخطاء مضيف LAN عديم الاستجابة

تحليل حدث الاتصال

مراجعة أحداث الاتصال من خلال تحديد الإعداد المسبق المضيفون في LAN غير قابلين للوصول في CMA. سيتم إنشاء أحداث عدم القدرة على الوصول إلى المضيف عندما لم يعد المضيف المعرّف متصلًا.

التحقق من قدرة وصول المضيف المحلي

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

  • تعتبر تحقيقات مراقبة الشبكة المحلية هي حزم ICMP مصدرها 10.254.254.1، لذلك من المهم التأكد من أن المضيف المراقب لديه طريق العودة إلى بوابة الشبكة المحلية للرد.
  • إذا كان الجهاز يعمل بجدار ناري محلي، فيجب السماح لحزم ICMP من عنوان IP 10.254.254.1.

قم بتشغيل التقاط الحزم من واجهة المستخدم على الويب وحدد أي مشاكل محتملة داخل الشبكة المحلية.

حل المشاكل المكتشفة

حل مشاكل التوجيه

إذا لم يتم العثور على المسار إلى المورد الداخلي في جدول التوجيه، تحقق وحل ما يلي:

  • إذا كان BGP مكوّنًا للموقع، تحقق من أن المسارات معلنة من قبل الجار. انظر إظهار حالة BGP. من المهم مراجعة البادئات BGP التي يعلن عنها جهاز التوجيه المحلي وتأكد من أن Cato تستقبلها.
  • إذا كانت جلسة BGP متوقفة، قم باستكشاف مشكلة الانفصال والتحقق منها. انظر جلسة BGP غير متصلة
  • تأكد من أن الموقع الذي يستضيف النطاق متاح. انظر استكشاف مشاكل اتصال الموقع

إذا كان مؤشر المسار المرئي في جدول التوجيه يسبب قرارات توجيه خاطئة، تحقق وحل التالي:

  • عادةً ما يتم ضبط قيم مؤشرات النفق من قبل Cato. يجب أن تحتوي المسارات الاحتياطية على نفس مؤشر النفق طالما كانت تنبثق من نفس نوع الموقع، مثل IPSec أو موقع Socket.
  • يمكن تكوين قيمة الوزن في CMA، الشبكة > الموقع > تكوين الموقع > BGP. سيظهر القيمة المعدلة على هذه الصفحة كوزن في جدول التوجيه. تغيير المؤشر للموقع سيصلح قرارات التوجيه الخاطئة للشبكات الاحتياطية.
  • قيم مؤشرات طول AS والتمييز تُستقبل من الموجه الخارجي. يجب تعديلها على هذا الجهاز إذا لزم الأمر.

حل حالات حظر IPS/Anti-Malware الإيجابية الزائفة

إذا كان المرور المثير للاهتمام محجوبًا بواسطة IPS/AM، يمكنك إضافة قوائم سماح بالنطاق WAN لكل من إعدادات IPS والبرمجيات الخبيثة.

 

حل مشكلة تطبيقات مخصصة متداخلة

تأكد من أن التطبيق المخصص يشمل العناوين الصحيحة، المجال، المنفذ، والبروتوكول. لا توجد منطقية في اختيار التطبيق المخصص للتحديد، لذا يجب تعريف التطبيق المخصص بشكل فريد لتفادي التداخل مع تطبيق مخصص آخر. لمزيد من المعلومات، انظر العمل مع التطبيقات المخصصة

ترتيب قواعد الجدار الناري

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

في الصورة أدناه، تحتوي القاعدة #1 على خدمة مخصصة تتضمن نطاقات IP لموقع twitter.com وتوضع فوق القاعدة #2 التي تحتوي على فئات التطبيقات. القاعدة #1 أكثر تحديدًا من القاعدة #2 وستكون مناسبة أفضل لحركة المرور الموجهة إلى twitter.com. سيساهم ذلك أيضًا في تعطيل تسريع TCP وحل أي مشاكل توجيه خارج السحابة أو Alt-WAN نظرًا لأن القاعدة #1 هي قاعدة بسيطة.

حل مشكلات عدم تطابق أسماء المجال

يمكن حل مشكلات مطابقة قواعد الجدار الناري بناءً على مجالات/FQDN كما يلي:

  • بالنسبة للبروتوكولات مثل HTTP/S، يمكن لـ Cato تحديد المجال من طلب GET أو SNI (من المصافحة TLS)، لذا من المهم فهم ما هي هذه الحقول (التي تظهر كـ اسم النطاق في الحدث FW) والتأكد من أنها معرفة في قاعدة الجدار الناري.
  • بالنسبة للبروتوكولات الأخرى، مثل SSH أو SMB، التي لا ترسل مجالًا كنص عادي، يعتمد Cato على اعتراض طلبات DNS والردود لتحديد المجال. هذا مهم بشكل خاص عند استخدام DNS خاص لأننا نحتاج إلى التأكد من أن استفسارات وإجابات DNS تمر عبر Cato. راجع أفضل الممارسات لـ DNS وحساب Cato الخاص بك
  • DoH (DNS فوق HTTPS) وDNS فوق TLS غير مدعومين لمطابقة أسماء النطاقات/التطبيقات، لذا يجب حظرهم في قواعد الجدار الناري لإجبار التوجيه نُسك DNS نحو UDP/53.

حل مشكلات توجيه DNS

يمكنك فقط استخدام توجيه DNS عندما تكون استفسارات DNS موجهة إلى خوادم DNS التالية:

  • خادم DNS الافتراضي لـ Cato 10.254.254.1
  • خوادم DNS على مستوى الحساب، مكونة تحت الشبكة > إعدادات DNS
  • خوادم DNS المعروفة مثل 8.8.8.8، 1.1.1.1، و 9.9.9.9. يمكن أن تختلف قائمة خوادم DNS المعروفة بين نقاط التواجد. على سبيل المثال، الصين وسيدني.

DoH (DNS عبر HTTPS) وDNS عبر TLS غير مدعومين لتوجيه DNS، لذا يجب حظرها في قواعد الجدار الناري لإجبار توجيه استفسارات DNS إلى UDP/53. ينطبق هذا الحل مخصوصًا على عملاء SDP لنظام macOS وiOS و Android.

 

رفع القضايا لدعم Cato

قدم تذكرة دعم بنتائج خطوات استكشاف الأخطاء المذكورة أعلاه. يرجى تضمين المعلومات التالية في التذكرة:

  • تفاصيل المشكلة التي تم تجربتها والتأثير العام على المستخدمين.
  • الفعاليات المتعلقة بالجدار الناري وتكوين قاعدة الجدار الناري.
  • إعادة إنتاج المشكلة وتفعيل الدعم الذاتي للخدمة. تضمين رقم التذكرة المُولدة بواسطة الأداة.
  • إذا كان المستخدم المتضرر يتصل بـ Cato باستخدام SDP Client، يرجى تسجيل المشكلة باستخدام SDP Client
  •  

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

0 من 0 وجدوا هذا مفيداً

لا توجد تعليقات