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

مشكلة

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

على سبيل المثال، يوضح اكتشاف الحدث أدناه حالات حاول فيها نفس المصدر الاتصال بنفس عنوان IP الهدف على نفس البروتوكول. ومع ذلك، بينما تم حظر اتصال واحد، تم السماح للآخر.

استكشاف الأخطاء وإصلاحها

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

1. التوجيه غير المتماثل

عندما لا يكون لـ Cato رؤية في التدفق بالكامل، قد يفتقر إلى المعلومات الكافية لتصنيف البيانات بدقة في التطبيق المناسب. وبالتالي، حتى لو كانت هناك قاعدة جدار ناري تسمح ببروتوكول محدد كـ HTTPS، فإن التوجيه غير المتناظر يمكن أن يؤدي إلى تصنيف التدفق خاطئًا كـ TCP. للأسف، يمكن أن يؤدي هذا التصنيف الخاطئ إلى حظر الاتصال لأنه لا يتوافق مع قاعدة الجدار الناري المسموح بها. للمزيد من التحقيق، يوصى بإجراء traceroute من المصدر إلى الوجهة والعكس عندما تحدث المشكلة. من خلال مقارنة المسارات الأمامية والعكسية، يمكننا التحقق ما إذا كان هذا بالفعل سبب المشكلة.

2. تطبيق مخصص متداخل

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

3. تأخير وعي المستخدم

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

4. FQDN في القاعدة

سيناريو شائع آخر حيث تتم معالجة اتصالات متشابهة ظاهريًا بشكل مختلف بواسطة Cato (محظورة أو مسموح بها) هو عندما يتم استخدام أسماء نطاق مؤهلة بالكامل (FQDN) في قواعد الجدار الناري أو في فئة/تطبيق مخصص. قبل أن نتعمق في التفاصيل، دعنا نفحص حدثين، كلاهما ينبع من نفس عنوان IP المصدر وموجه إلى نفس عنوان IP والمنفذ، ولكن بنتائج مختلفة - واحدة مسموح بها والآخر محجوب.

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

في المثال المعطى، يتم حظر الاتصال أو السماح به بناءً على قاعدة الجدار الناري WAN.

للبحث بشكل أعمق، اتبع هذه الخطوات:

• انتقل إلى قسم الجدار الناري WAN داخل CMA وابحث عن القواعد ذات الصلة.

• يتضح أن القاعدة 1 تتناظر مع حدث المراقبة (السماح). تسمح هذه القاعدة تحديدًا بالاتصالات المصنفة تحت "خوادم ويب داخلية". تشير هذه القاعدة إلى أن "خوادم ويب داخلية" تأتي من فئة مخصصة.

• في المقابل، تتناسب القاعدة 5 مع الحدث المحظور. تم تصميمها لحظر حركة مرور HTTP(s) إلى جانب خدمات أخرى.

راجع التطبيق/الفئة

• انتقل إلى الموارد > الفئات > الفئات المخصصة

• في قائمة الفئات المخصصة، ابحث وحدد الفئة "خوادم ويب داخلية".

• ضمن تفاصيل الفئة، لوحظ أن العضو في فئة "خوادم ويب داخلية" يتطابق مع اسم النطاق المؤهل بالكامل (FQDN) إلى webserver.dyow-homelab.com.

• هذا يشير إلى أن الاتصال المتطابق مع FQDN سيتم السماح به. (لكي يقوم Cato بتحديد اسم المضيف بشكل صحيح، نحتاج إلى رؤية استعلام/استجابة DNS)
  

• أي اتصال لا يتطابق مع FQDN الدقيق سيتم رفضه. على سبيل المثال، إذا كان الموقع الذي تمت زيارته يتضمن "www"، أي www.webserver.dyow-homelab.com (وفقًا لاستعلام DNS)، فلن يتطابق مع الاسم المؤهل بالكامل المحدد في CMA. لحل هذه المشكلة، يمكن تعريف كائن نطاق بدلاً من ذلك. هذا سيسمح بالتطابق إلى جميع النطاقات الفرعية التي تشمل النطاق المحدد. راجع Cato WAN Firewall.
  
• في المثال المحظور أعلاه، حاول المستخدم الوصول إلى الخادم باستخدام عنوان IP الوجهة بدلاً من FQDN. في هذه الحالة، نظرًا لعدم وجود أي استعلام/استجابة DNS، لم يتمكن Cato من تحديد اسم المضيف، ولم تطابق القاعدة.
• في الحالات التي يحدث فيها الوصول المباشر إلى عنوان IP دون طلب DNS مسبق، يستخدم Cato ذاكرته المؤقتة لمحاولة مطابقة النطاق مع عنوان IP المعطى. إذا لم تحتوي الذاكرة المؤقتة على أي نطاقات، فسيكون Cato غير قادر على ربطها باسم مضيف أو FQDN. بالتالي، سيتم حظر الاتصال في المثال المذكور أعلاه.
• لذلك، عند تكوين قاعدة جدار ناري للسماح بناءً على FQDN، يجب على العميل الوصول إلى الخادم باستخدام اسم النطاق لضمان الاتصال المستمر.
  ملاحظة: إذا كنت تستخدم DNS خاص، فنحن بحاجة إلى التأكد من أن استعلامات/ردود DNS تمر عبر Cato. لممارسات DNS الأفضل، راجع أفضل الممارسات لـ DNS وحساب Cato الخاص بك 

حلول بديلة

في حال استمرار حدوث أخطاء في تطابق قواعد الجدار الناري، حتى بعد الوصول إلى الموقع باستخدام اسم النطاق الخاص به وبالفعل تتجه استعلامات/ردود DNS عبر Cato، يمكن تنفيذ الحلول التالية:

• قد تكون ذاكرة التخزين المؤقت لـ DNS في جهاز الكمبيوتر الخاص بالمستخدم مختلفة عن ذاكرة التخزين المؤقت لـ DNS في PoP مما يؤدي إلى عدم قيام Cato بربط عنوان IP الخادم بـ FQDN. في الحالات التي يتم فيها استخدام خادم DNS داخلي، يمكن تقصير TTL لـ DNS (وقت العيش) وبالتالي إجبار الكمبيوتر لتوليد استعلامات DNS بشكل متكرر.
• استخدم دمج عنوان IP/المنفذ في التطبيق المخصص/الفئة المستخدمة في قاعدة الجدار الناري التي تطابق الخادم. في المثال أعلاه، اضبط التطبيق المخصص على عنوان IP 192.168.2.25 والمنفذ 8080. سيجبر هذا تطابق القاعدة حتى لو كانت هناك اختلافات في ذاكرة التخزين المؤقت لـ DNS أو استفسارات DNS المفقودة عبر Cato Cloud.