اختبار أداء جدار الحماية باستخدام Xena VulcanBay

في حالة الاختبار الملموسة هذه، استخدمنا منصة Xena VulcanBay مع واجهتي QSFP+ بسرعة 2 جيجابت في الثانية لاختبار أداء بعض جدران الحماية من الجيل التالي. وقد اهتممنا تحديدًا بسيناريوهات الاختبار التالية:

• معدل إنتاج نقي
• عدد كبير من الاتصالات (حمل الجلسة)
• استخدام NAT
• حركة مرور واقعية
• فترات اختبار أطول قمنا خلالها "بدفع" قواعد جدار الحماية الجديدة للكشف عن خروقات الإنتاجية المحتملة

في هذه المقالة، سنوضح كيفية استخدامنا لـ Xena VulcanBay، بما في ذلك إدارته، وVulcanManager، ومحول Cisco Nexus Switch لربط مجموعات جدران الحماية. نسرد سيناريوهات الاختبار التي أجريناها، ونقدم بعض التلميحات حول العقبات المحتملة.

لاختباراتنا، استخدمنا وحدة تحكم Xena VulcanBay Vul-28PE-40G بإصدار البرنامج الثابت 3.6.0، مع تراخيص لواجهات 40 جيجابايت، و28 محرك حزم متوفرًا. كان VulcanManager يعمل بالإصدار 2.1.23.0. ولأننا استخدمنا محرك VulcanBay واحدًا فقط (وليس عدة محركات في مواقع موزعة)، فقد تمكن مستخدم الإدارة الوحيد من توزيع محركات الحزم الـ 28 بالتساوي على هذين المنفذين.

 

بالنسبة للاختبارات التي يصل معدل إنتاجها إلى 80 جيجابايت، كان استخدام وحدتي QSFP+ (على اليسار) بالإضافة إلى توزيع محركات الحزم على هذه المنافذ (على اليمين) كافياً.الأسلاك

استخدمنا مُبدِّل Cisco Nexus واحدًا مزودًا بوحدات QSFP+ كافية ومعدل نقل البيانات المُناسب لتوصيل VulcanBay بمجموعات جدران الحماية المُخصصة. ونظرًا لأننا قمنا بتوصيل جميع مجموعات جدران الحماية، بالإضافة إلى VulcanBay، بهذا المُبدِّل في الوقت نفسه، واستخدمنا دائمًا نطاقات عناوين IPv4/IPv6 نفسها للاختبارات، فقد تمكنا من تحديد مُصنِّع جدار الحماية الذي نريد اختباره فقط مع "إيقاف/عدم إيقاف" كل واجهة على حدة. وهكذا، أصبح المختبر بأكمله قابلًا للتحكم عن بُعد. وهو أمر عملي للغاية في الحالات النموذجية لموظفي المكاتب المنزلية. علاوة على ذلك، كان من السهل جدًا توصيل VulcanBay "بذاته" للحصول على قيم مرجعية مُفيدة لجميع الاختبارات. ولهذا الغرض، تم تكوين واجهتي 40 جيجابت المُتصلتين بـ VulcanBay مؤقتًا في نفس شبكة VLAN.

 

مع وجود خطين لكل من العميل والخادم، تم توصيل جميع مجموعات جدران الحماية بمحول مركزي. كما تم استخدام VulcanBay من Neox Networks.

توجد مفاتيح مزودة بوحدات QSFP+، والتي تم تصميمها على أنها 4x 10 G و*ليس* 1x 40 G. بالنسبة لتوصيل VulcanBay بواجهات 40 G الخاصة به، فإن الأخير أمر لا مفر منه.

 

بفضل فتحات QSFP+ الحديثة ذات واجهات 40 جيجابت، يمكن تحقيق معدل نقل مزدوج يبلغ 80 جيجابت/ثانية باستخدام اتصالين فقط.شبكات IP الفرعية

في حالتنا، أردنا اختبار جدران حماية مختلفة في وضع الطبقة الثالثة. ولدمج توجيه "الجهاز قيد الاختبار" (DUT)، أنشأنا شبكات فرعية مناسبة - لبروتوكول IPv4 القديم وكذلك لبروتوكول IPv6. ثم يتم ربط شبكات IP الفرعية التي يحاكيها VulcanBay مباشرةً بجدار الحماية. في حالة استخدام شبكة IPv4 من نوع /16 networkهذا بالضبط /16 network يجب أيضًا ضبطها على جدار الحماية. ومن المهم بشكل خاص البوابة الافتراضية، على سبيل المثال 10.0.0..1 لعنوان IPv4 الخاص بالعميل. networkإذا استخدمتَ خيار "استخدام ARP" (على الجانب الأيمن)، فلن تحتاج إلى القلق بشأن عناوين MAC المعروضة، حيث يقوم جهاز VulcanBay بحلّها تلقائيًا.

 

يجب تعديل نطاق العنوان بحيث لا تكون الاختبارات التي تم إجراؤها مكافئة لفيضان MAC.

وينطبق الأمر نفسه على بروتوكول IPv6. هنا network لا يتم إدخال العنوان باستخدام صيغة الشرطة المائلة المعتادة، بل يتم تحديد البوابة ونطاق العناوين فقط. عبر خيار "استخدام بروتوكول اكتشاف الشبكة" (NDP)، ​​يقوم جهاز VulcanBay تلقائيًا بتحويل عنوان MAC من الطبقة الثانية إلى عنوان IPv6 من الطبقة الثالثة.

 

يخبر "استخدام البوابة" VulcanBay بأنه يجب استخدام جهاز توجيه/جدار حماية وسيط لإجراء الاختبارات.

إغراق عناوين MAC! بناءً على سيناريوهات الاختبار المستخدمة، قد يُحاكي VulcanBay ملايين عناوين IPv4/IPv6 في شريحة العميل أو الخادم. هذا إغراق كامل لعناوين MAC لكل مفتاح وسيط أو جدار حماية. يمكن أن تحتوي الأوزان الشائعة عالية الأداء على 128 ألف عنوان MAC كحد أقصى في جدول عناوين MAC الخاص بها. إذا تركت النطاق الافتراضي البالغ 16 مليون عنوان IPv4، أو 1.8 × 10^19 عنوان IPv6 الذي تُحدده شبكات Xena افتراضيًا، فإن أي نتائج اختبار لا قيمة لها. لذلك، نوصي بشدة بتقليل نطاقات العناوين من البداية إلى قيم واقعية، كما هو موضح في لقطة الشاشة أعلاه (المُعلّمة باللون الأصفر: 65 ألف عنوان).

وللمقارنة، تم توصيل جهاز VulcanBay بنفسه في جميع الاختبارات. بينما سمح بروتوكول IPv4 باستخدام نفس "الشبكات الفرعية". networkمع نطاقات عناوين مختلفة، تتطلب IPv6 شبكات فرعية ضمن البادئة /64 نفسها.حالات الاختبار

١) معدل نقل البيانات: في سيناريو الاختبار الأول، انصبّ اهتمامنا على معدل نقل البيانات لجدران الحماية. لذلك، اخترنا سيناريو "النمط"، مرة لبروتوكول IPv1 ومرة ​​لبروتوكول IPv4، والذي يُعيّن النسبة تلقائيًا إلى ٥٠-٥٠. في الإعدادات، اخترنا أيضًا "ثنائي الاتجاه" لتمرير البيانات في كلا الاتجاهين، أي ثنائي الاتجاه، في كلتا الحالتين. وهكذا، تمكنا من الوصول إلى معدل نقل بيانات أقصى قدره ٨٠ جيجابت في الثانية باستخدام واجهتي ٤٠ جيجابت في الثانية. لتوزيع النطاق الترددي على عدة جلسات (وهي في الواقع حالة الاختبار الأكثر واقعية)، اخترنا ١٠٠٠ مستخدم، والذين يجب عليهم إنشاء اتصالات من ١٠٠ منفذ مصدر إلى ١٠ خوادم لكل جلسة. ينتج عن ذلك مليون جلسة لكل من بروتوكولي IPv6 وIPv50. مع وقت بدء تشغيل قدره ٥ ثوانٍ، أي زيادة سلسة في عدد الاتصالات بدلاً من التحميل الكامل الفوري، استمر الاختبار لمدة ١٢٠ ثانية بعد ذلك، قبل أن يكون لديه أيضًا وقت انخفاض قدره ٥ ثوانٍ.

 

سيناريو اختبار "النمط" بتوزيع متساوٍ لبروتوكولي IPv50 وIPv50. يُظهر "ملف تعريف التحميل" (على اليمين) المستخدمين المطلوب محاكاتهم باستخدام محور الوقت.

أثناء الاختبار، يعرض VulcanManager بعض البيانات المفيدة، مثل اتصالات TCP أو معدل نقل البيانات للطبقة الأولى. من خلال الرسومات في المنطقة العلوية، يُعطي انطباعًا جيدًا للوهلة الأولى. في لقطة الشاشة التالية، يمكنك أن ترى أن عدد الاتصالات النشطة أقل من نصف العدد المخطط له (سيئ)، بينما يُظهر معدل نقل البيانات الجيد للطبقات من 1 إلى 5 عيبًا غير مرغوب فيه في بداية الاختبار. تبيّن أن كلتا المشكلتين ناتجتان عن أخطاء في تطبيق IPv7 للجهاز المُختبر.

 

في حين أنه من الناحية النظرية كان من المفترض أن تمر 2 مليون جلسة بمعدل إنتاج 80 جيجابايت عبر جدار الحماية، إلا أن أقل من نصفها نجح في المرور بشكل نظيف.

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

٢) عدد كبير من الاتصالات (حمل الجلسة): أيضًا بالنسبة لبروتوكولي IPv2 وIPv4، تم إنشاء 6 مليون جلسة TCP متوازية وصيانتها خلال هذا الاختبار. لم يكن مجموع الجلسات مهمًا فحسب، بل كان أيضًا وقت بدء التشغيل القصير (20 ثانية فقط)، والذي يتوافق مع معدل إعداد يبلغ 30 اتصال في الثانية! تُركت الجلسات لمدة 667,000 ثانية، ولكن دون نقل أي بيانات. على مدار 60 ثانية أخرى، تم إنهاؤها مرة أخرى، وهو أمر شائع في بروتوكول TCP عبر FIN-ACK. كان الهدف هو أن تسمح جدران الحماية المراد اختبارها أولًا بمرور الاتصالات بسلاسة، وثانيًا، أن تتمكن من تفكيكها بسلاسة (وبالتالي تحرير ذاكرتها).

قبل كل اختبار، حذفنا جدول عناوين MAC على المُبدِّل، بالإضافة إلى ذاكرة التخزين المؤقت للجلسة وARP وNDP على جدران الحماية. وهكذا، أُجري كل اختبار من الصفر إلى الصفر.

3) سيناريوهات NAT: تم استخدام نفس الاختبار المذكور في البند 1)، مع الاختلاف الوحيد في اتصالات IPv4 من العميل. network إلى الخادم network تم تزويد جدران الحماية بخاصية ترجمة عناوين الشبكة المصدرية (NAT). وكان الهدف هو معرفة ما إذا كان ذلك سيؤدي إلى تدهور أداء جدران الحماية.

٤) حركة مرور واقعية: باستخدام "مزيج مركز البيانات" المُحدد مسبقًا، تمكنا من محاكاة تدفق اتصالين HTTPS وSMB4 وLDAP وAFS (عبر UDP وTCP) لآلاف المستخدمين ببضع نقرات فقط. لم يكن الأمر يتعلق باختبار تحميل كامل لجدران الحماية، بل بسرعات الإعداد والتفكيك، بالإضافة إلى اكتشافات التطبيقات. وُجدت اختلافات كبيرة بناءً على ما إذا كانت مُعرّفات تطبيقات جدران الحماية مُفعّلة أم مُعطّلة.

٥) ١٠ دقائق من التشغيل المتواصل مع الالتزامات: تألف هذا الاختبار، الأكثر تحديدًا، من السيناريوهين ١ و٤، أي التحميل الكامل (١) مع إعداد جلسة ثابتة وإيقافها (٤) في الوقت نفسه. استمر هذا لمدة ١٠ دقائق، بينما ثبّتنا ٥٠٠ قاعدة أخرى على كل جدار حماية. أردنا هنا معرفة ما إذا كانت هذه العملية تُحدث خللًا ملموسًا في معدل نقل البيانات على جدران الحماية، وهو ما حدث جزئيًا.نتائج الإختبار

في نهاية كل اختبار، يعرض VulcanManager صفحة الإحصائيات والتقارير مع جميع التفاصيل الممكنة. من خلال "إنشاء تقرير"، يمكنك إنشاء ملف PDF يحتوي، بالإضافة إلى جميع التفاصيل، على معلومات حول سيناريو الاختبار المحدد ومعلومات حول الجهاز المُختَبَر. يكمن التحدي في التمييز بين الأرقام ذات الصلة والأقل صلة، ووضعها في السياق الصحيح للحصول على نتائج ذات معنى. خلال مقارناتنا لمختلف جدران الحماية من الجيل التالي، اقتصرنا على "معدل نقل البيانات الثابت من الطبقة الأولى (بت في الثانية)" لاختبار معدل النقل، أو "اتصالات TCP الناجحة" لاختبار الاتصال. بالمقارنة مع القيم المرجعية التي تم بها توصيل VulcanBay بنفسه، أسفر هذا بالفعل عن نتائج قابلة للمقارنة وذات معنى، يمكن عرضها بسهولة في شكل جدول ورسوم بيانية.

 

توفر صفحة الإحصائيات والتقارير نظرة عامة تقريبية (في المنتصف) وإمكانية قراءة قيم الاختبار من جميع طبقات OSI وسيناريوهات الاختبار المحددة (الروابط، علامات التبويب القابلة للطي).

 

تفاصيل التقرير بصيغة PDF مع كافة التفاصيل.

لا تُتيح سيناريوهات "مزيج التطبيقات" المختلفة الموجودة في Xena Networks إجراء مقارنة مباشرة لقيم أداء جدار الحماية، ولكن التوليد المستهدف لـ network حركة المرور. بهذه الطريقة، يمكن التحقق من اكتشافات التطبيقات أو يمكن "إجهاد" السيناريوهات الأخرى التي يتم تنفيذها بالتوازي بشكل أكبر قليلاً.المزيد من الميزات

تجدر الإشارة إلى أن VulcanManager يحتوي على ميزات أخرى مثيرة للاهتمام لم نستخدمها في دراسة الحالة هذه، مثل TLS Traffic (لاختبار اعتراض TLS) وPacket Replay (لاختبار سيناريوهات مخصصة وأكثر تحديدًا مستخرجة من PCAPs المُحمّلة). كما أننا لم نستخدم العديد من سيناريوهات الاختبار الموجهة للتطبيقات أو البروتوكولات مثل Dropbox وeBay وLinkedIn أو HTTPS وIMAP وNFS. ويعود ذلك إلى أن أغراض الاختبار لدينا ركزت بشكل كبير على الإنتاجية وعدد الجلسات.خاتمة

يُعدّ VulcanBay من XENA Networks جهاز الاختبار الأمثل لمقارنة مختلف جدران الحماية من الجيل التالي. في غضون فترة قصيرة جدًا، قمنا بتكوين واختبار سيناريوهات اختبار مختلفة. كانت وفرة نتائج الاختبارات هي العامل الحاسم في البداية. كان الحل هو التركيز على المعلومات ذات الصلة.