أداء قاعدة الشبكة - تحليل المشاكل

نظرة عامة

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

الأعراض

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

• عنوان IP العام غير صحيح
• عدم تطابق قاعدة الشبكة
• تم اختيار واجهة WAN غير صحيحة
• يتم تطبيق تسريع TCP أو تجاوزه
• عدم تطابق أولوية QoS
• كسر اتصالات المرور في السحابة أو بديل WAN

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

• عدم تطابق التطبيق المخصص أو المدمج
• عدم تطابق المجال
• اختيار نقطة خروج خاطئة
• وصلات WAN غير صحية
• تسبب التطبيق المحظور أو غير المحدد إلى تثبيت أولوية QoS
• ترتيب قواعد الشبكة بشكل خاطئ

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

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

تأكد من مراجعة القسم المناسب لحل المشاكل من خلال تحديد الأعراض المذكورة من قبل المستخدمين:

• قد تبلغ تطبيقات الويب عن عنوان IP مصدر عام مختلف عن ذلك الذي تم تكوينه في قاعدة الشبكة. إذا كانت حقول اسم نقطة خروج و عنوان مصدر IP العام في الحدث الجدار الناري ليست كما هو متوقع، انظر حل مشاكل عنوان IP المصدر العام غير الصحيح
• تحقق مما إذا كان حقل قاعدة الشبكة في حدث الجدار الناري هو كما هو متوقع. إذا لم يكن، استمر في حل مشكلات عدم تطابق قاعدة الشبكة
• إذا لم تستخدم تدفقات المرور الرابط WAN الأساسي المكون أو لم تكن متوازنة كما تم تكوينه في قسم النقل الأساسي لقاعدة الشبكة، انظر حل مشكلات اختيار واجهة WAN غير الصحيحة
• إذا كان حقل تسريع TCP من حدث الجدار الناري ليس القيمة المكونة المتوقعة في قاعدة الشبكة، انظر حل المشكلات تنفيذ أو تجاوز تسريع TCP
• إذا تم تعيين حركة المرور إلى الأولوية الخاطئة QoS من 255 كما هو حسب الحدث الجدار الناري، انظر حل مشاكل عدم تطابق أولوية QoS
• إذا كانت اتصالات TLS تفشل عندما يتم اختيار خارج السحابة أو البديل WAN كوسيلة النقل في قاعدة الشبكة، انظر حل مشكلات كسر اتصالات المرور خارج السحابة أو Alt-WAN 

حل المشكلة

حل مشاكل عنوان مصدر IP العام غير الصحيح

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

مراجعة عدة عناوين IP للخرج

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

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

لتغيير هذا السلوك، انظر تغيير اختيار نقطة خروج.

عناوين IP غير متاحة

قد يكون من الممكن أن قواعد الشبكة تحتوي على عنوان IP واحد للخرج ستخرج حركة المرور باستخدام عنوان IP عام مختلف عن ما هو مُعد. هذا يمكن أن يكون ممكن عندما تكون نقطة الخروج المرتبطة بعنوان IP للخرج غير متاحة مؤقتاً خلال نافذة الصيانة. قد تكون هذه الحالة حرجة، خاصة لتطبيقات VoIP.

لتغيير هذا السلوك، انظر تغيير اختيار نقطة خروج.

مراجعة تغييرات قواعد الشبكة

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

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

حل مشاكل عدم تطابق قواعد الشبكة

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

تحليل حدث الجدار الناري

حدد الحقول ذات الصلة مثل التطبيقات المتعلقة، التطبيق، تطبيق كاتو، عنوان IP للوجهة، اسم المجال، و<ني>قاعدة الشبكة من حدث الجدار الناري. ستساعدك هذه المعلومات على تحليل سبب عدم تطابق قاعدة الشبكة.

التحقق من استثناءات قواعد الشبكة

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

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

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

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

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

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

• ما هي التطبيقات المُعدة في قاعدة الشبكة "الخاطئة" التي تطابقها.
• ما إذا كان أي من هذه التطبيقات مدرج في حقل التطبيقات المتعلقة من حدث FW.

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

في المثال أدناه، الوصول إلى portal.azure.com يتطابق مع القاعدة رقم 7 بدلاً من القاعدة رقم 8. هذا لأن القاعدة رقم 7 تتضمن التطبيق Microsoft Azure (المتضمنة في التطبيقات المتعلقة) على الرغم من أن التطبيق النهائي (حقل التطبيق) هو Azure Front Door.

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

التحقق من اسم المجال

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

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

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

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

حل مشاكل اختيار واجهة WAN غير الصحيحة

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

مراجعة تكوين نقل قواعد الشبكة

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

مراجعة تحليلات الشبكة

ستظهر أداة الوسط الحسابي للإنتاجية استخدام BW المتوسط لكل رابط WAN. قد تكون هذه بمثابة مؤشر لتأكيد أن قاعدة الشبكة تختار الاتصال WAN الصحيح أو توازن المرور بشكل صحيح. في الصورة أدناه، تم تعديل قاعدة الشبكة لاختيار WAN2 كوسيلة النقل الأساسية.

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

مراجعة واجهة مستخدم شبكة المقبس

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

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

التحقق من تكوين رابط WAN

إذا كانت جميع الروابط الذكية/الذكية نشطة، تحقق من تكوين عرض النطاق لكل رابط WAN في CMA. في المثال أدناه، تم تكوين رابط WAN1 بعرض نطاق 100 ميجا بايت في الدقيقة للأسفل/للأعلى، وتم تكوين رابط WAN2 بـ 20 ميجا بايت في الدقيقة للأسفل/للأعلى. سينتج عن ذلك إرسال المزيد من المرور إلى WAN1 بنسبة 100:20 أو 5:1 لكلا الاتجاهين الصاعد والمنزل.

حل مشاكل تنفيذ أو تجاوز تسريع TCP

كما تمت مناقشته في شرح تسارع TCP لـ كاتو، يمكن تمكين تسارع TCP في قاعدة شبكة لتسريع اتصالات TCP عبر WAN. يتم عادةً تنفيذ هذه الميزة في سيناريوهات معينة قد لا يكون المدير قادرًا على تعطيلها حتى إذا كانت خيار تسريع TCP نشط في القاعدة غير محدد. يعالج هذا القسم تلك السيناريوهات وكيفية تعطيل الميزة عند الحاجة.

عندما يتم تنفيذ تسارع TCP

سيتم تنفيذ تسارع TCP عندما تستخدم قاعدة الشبكة عنوان IP للخرج أو موقع للخرج. يجبر هذا النقطة للعمل كوكيل مما بدوره ينفذ تسارع TCP لجميع تدفقات المرور التي تطابق القاعدة. سيكون مربع الاختيار في قاعدة الشبكة مظلل باللون الرمادي.

تعطيل تسارع TCP في قاعدة الشبكة لن يعطل هذه الميزة عندما:

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

قاعدة الشبكة المعقدة (المعروفة أيضا باسم قاعدة NG) هي قاعدة شبكة لا يمكن للمقبس نفسه تقييمها. لذلك، يجب على الSocket إرسال حركة المرور إلى الPoP لاختيار القاعدة الشبكية الصحيحة التي تمكن تسريع الTCP. قد تحتوي على: تطبيقات، فئات التطبيقات، خدمات، تطبيقات مخصصة، أو كائنات النطاق/FQDN.

من ناحية أخرى، قد تحتوي القاعدة البسيطة على الكيانات التالية التي يمكن تقييمها من قبل الSocket ولا تحتاج تدخل من الPoP:

• في حقل المصدر/الوجهة: المواقع، عناوين IP، واجهات الشبكة، نطاق IP، أو أخرى.
• في حقل التطبيق/الفئة: نطاق المنفذ أو خدمة مخصصة.

عند تخطي تسريع الTCP

سيتم تطبيق تسريع الTCP فقط على حركة مرور الTCP. في حال تم تفعيل تسريع الTCP في القاعدة الشبكية أو فرضه كما هو موضح في القسم السابق، ولكن حقل تسريع الTCP في حدث CMA هو 0، فمن الممكن أن التوجيه غير المتناظر عبر Cloud كاتو يسبب في اكتشاف تدفق الحركة كالوضع المفتوح

كما هو موضح في التوجيه غير المتناظر عبر كاتو، فإن الوضع المفتوح هو وضع اتصال لا تكون فيه Cloud كاتو على دراية ببداية تدفق الTCP (٣). نوصي بالعمل مع دعم كاتو لتحديد السبب الجذري لخلق تدفقات الوضع المفتوح.

تعطيل تسريع الTCP

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

استكشاف أخطاء الأولويات غير المتطابقة للQoS

كما هو موضح في متى يتم تعيين أولوية QoS لتدفق بأولوية 255، يمكن أن يكون هناك حالات حيث أن أولوية QoS المكونة في القاعدة الشبكية تختلف عن الأولوية المعروضة في الحدث FW.

تُعتبر أولوية QoS 255 بمثابة الأولوية الافتراضية لإدارة BW. هناك عدة أسباب لماذا يمكن تعيين تدفق لأولوية QoS 255 بغض النظر عن تكوين الأولوية في القاعدة الشبكية BW:

• تقوم كاتو بتقييم الملف الشخصي للشبكة لكل تدفق، ويتم تعيين أولوية QoS إلى 255 عندما لم يتم بعد تحديد التطبيق المحدد.
• يتم تعيين الأولوية 255 لأول الحزم (قبل تحديد التدفق).
• يتم تعيين أولوية QoS 255 للتدفقات المحظورة.

استكشاف أخطاء كسر الروابط خارج السحابة أو Alt-WAN  

يتناول هذا القسم السيناريو الذي تفشل فيه اتصالات TLS في الإنشاء بين المواقع عندما يتم تكوين قاعدة شبكة WAN مع خارج السحابة أو Alt-WAN كالنقل الأساسي. لاستكشاف هذه المشكلة، اتبع الخطوات أدناه.

تحليل التدفق

عندما يتم توجيه الحركة بشكل صحيح عبر خارج السحابة أو Alt-WAN، فلن تولد التدفقات الحدث FW في CMA لأن هذه الحركة لا تمر عبر الPoP.

إحدى الطرق لتأكيد أن الحركة يتم توجيهها بنجاح عبر خارج السحابة أو Alt-WAN هي من علامة التبويب SDWAN في Socket WebUI. حدد تدفق الحركة النشطة وتحت الNIC المختار سترى النقل المختار للحركة المثيرة للاهتمام. إذا لم يتم اختيار النقل المتوقع، فتأكد من أن خارج السحابة أو Alt-WAN مكونة بشكل صحيح.

التحقق من ترتيب القواعد الشبكية

كما هو موضح في فشل اتصال TLS عبر روابط خارج السحابة أو Alt-WAN، عندما تكون الحركة TLS ويكون تفتيش TLS مفعلا، فإن ترتيب القواعد الشبكية هو عامل مهم لضمان تدفق الحركة عبر روابط خارج السحابة أو Alt-WAN.

لا يمكن للSockets تقييم القواعد الشبكية وتوجيه الحزم عبر خارج السحابة أو Alt-WAN عندما تكون القاعدة الشبكية التي تصطدم بها الحركة أسفل القاعدة المعقدة. لحل هذا السلوك المتوقع، راجع ترتيب القواعد الشبكية

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

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

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

ترتيب القواعد الشبكية

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

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

حل مشاكل اسم النطاق

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

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

  • رأس اسم مضيف HTTP (عند تفعيل فحص TLS)

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

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

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

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

تغيير اختيار Egress PoP

إذا كنت ترغب في توجيه جميع قواعد الإخراج للحساب عبر الPoP الأقرب إلى الوجهة، بدلاً من الأقرب إلى المصدر (السلوك الافتراضي)، يرجى الاتصال بدعم شبكات كاتو عبر رفع قضية لدعم كاتو.

بالنسبة لتطبيقات VoIP التي تستخدم بروتوكول SIP الذي يتطلب دائمًا استخدام نفس عنوان Egress IP، فعل خيار IP المفضل لحركة مرور SIP في الإعدادات المتقدمة.

إذا كان بروتوكول آخر لVoIP أو أي تطبيق آخر يتطلب دائمًا استخدام نفس عنوان Egress IP، يرجى الاتصال بدعم شبكات كاتو عبر رفع قضية لدعم كاتو.

رفع قضية لدعم كاتو

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

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