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

التعيين

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

الأعراض

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

• لا يمكن حل اسم نطاق السيرفر الداخلي

• السيرفر الداخلي لا يمكن الوصول إليه

• عدم تطابق قاعدة جدار الحماية WAN

• لا يستطيع عملاء SDP الوصول إلى الموارد الداخلية

• (المورد RPF لإعادة توجيه المنفذ البعيد لا يمكن الوصول إليه

• مضيف المراقبة LAN غير قابل للوصول

الأسباب الممكنة

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

• سوء تكوين إعادة توجيه DNS

• سوء تكوين جدار الحماية WAN

• تداخل مع شبكة عميل SDP

• تدخل الأمان

• مشاكل الاتصال مع مضيف الوجهة

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

تنويه:

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

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

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

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

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

• تحقق مما إذا كان يمكن الوصول إلى عنوان IP الخاص بالخادم عن طريق تنفيذ أمر ping. تأكد من السماح لـ ICMP بواسطة قاعدة جدار حماية WAN قبل إجراء هذا الفحص. إذا لم يتم استلام استجابة ping، انتقل إلى استكشاف الوصول إلى السيرفر الداخلي غير القابل للوصول

• إذا أظهرت أحداث IPS أو مكافحة البرمجيات الخبيثة أن أي من هذه المحركات يحجب الوصول إلى الخادم الداخلي، انتقل إلى حل حجبات IPS/مكافحة البرمجيات الخبيثة الإيجابية الكاذبة

• تحقق مما إذا كانت القاعدة المطابقة في حدث جدار حماية WAN هي المتوقعة. إذا لم تكن كذلك، استمر في استكشاف عدم تطابق قاعدة جدار الحماية

• إذا تم التأثير فقط على عملاء SDP وليس على المستخدمين خلف المواقع، انتقل إلى استكشاف وصول عميل SDP إلى الموارد الداخلية

• إذا كان المورد الداخلي المتأثر يمكن الوصول إليه عبر إعادة توجيه المنافذ البعيدة، انتقل إلى استكشاف الموارد الداخلية لرسم الخرائط RPF

• إذا كان السيرفر المتأثر مراقبًا بواسطة مراقبة LAN، تحقق من استكشاف الوصول إلى مضيف مراقبة LAN

استكشاف المشكلة وحلها

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

مراجعة سجلات مسار التدقيق

راجع مسار التدقيق لأي سجلات محورة قد أثرت على الوصول إلى الموارد الداخلية. يشمل ذلك قواعد جدار الحماية 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 هو تطابق كامل للنطاق المؤهل بالكامل. على سبيل المثال، الاسم الفريد المؤهل 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.

تنويه:

قد تُظهر أحداث RPF الواردة أحيانًا اسم العرض للمستخدم، حتى لو لم يتم بدء حركة المرور من قبل المستخدم. هذا سلوك متوقع.  

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

هذا يختلف عن كيفية تفسير سياسات الجدار الناري أو التوجيه لحركة المرور (التي تدرك الاتجاه)، لكنه طبيعي لأجل ترابط الأحداث.   

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

راجع أي أحداث موجهة إلى عنوان 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 والبرمجيات الخبيثة.

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

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

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

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

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

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

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

• بالنسبة لبروتوكولات مثل HTTP/S، يمكن لـ Cato تحديد مجال الوجهة باستخدام المصادر التالية:

  • عنوان مضيف HTTP (عندما يتم تمكين فحص TLS)

  • حقل SNI أثناء مصافحة TLS

  • حل DNS، حيث يتم تعلم اسم المجال من استعلامات واستجابات DNS

• من المهم التأكد من أن المجال المخصص في قاعدة الجدار الناري متسق عبر كل هذه المصادر. لاحظ أنه يتم عرض فقط اسم المجال الأفضل تطابقاً (المُقيم من الأعلى إلى الأسفل) كـ اسم المجال في أحداث الجدار الناري. 

• بالنسبة للبروتوكولات الأخرى، مثل SSH أو SMB، التي لا ترسل نطاقًا كنص عادي، يعتمد "كاتو" حصريًا على اعتراض DNS لربط حركة المرور بنطاق أو FQDN. هذا مهم بشكل خاص عند استخدام DNS خاص حيث نحتاج إلى التأكد من أن استفسارات DNS / الردود تمر عبر Cato. راجع أفضل الممارسات لDNS وحساب كاتو الخاص بك

• لا يتم دعم 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 باستخدام SDP Client، يرجى تسجيل المشكلة باستخدام SDP Client