أستكشاف أخطاء التجزئة وإصلاحها: يؤثر على وحدة التحكم اللاسلكية C9800 مع Azure

المقدمة

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

الأعراض

المنتجات المتأثرة: وحدة التحكم اللاسلكية Catalyst 9800-CL المستضافة على Azure أو Identity Service Engine المستضافة على Azure.

إعداد SSID: مهيأ ل 802.1x EAP-TLS بمصادقة مركزية.

السلوك : عند إستخدام قائمة 9800-CL المستضافة على النظام الأساسي Azure باستخدام SSID المستندة إلى EAP-TLS، يمكنك مواجهة مشاكل الاتصال. قد يواجه العملاء صعوبات أثناء مرحلة المصادقة.

خطأ على خادم ISE

رمز الخطأ 5411 الذي يشير إلى أن الطالب قد أوقف الاتصال مع ISE أثناء تبادل شهادات EAP-TLS.

تحليل السجل التفصيلي:

فيما يلي مثال على أحد التكوينات المتأثرة: في وحدة التحكم اللاسلكية 9800، يتم إعداد SSID ل 802.1x، ويتم تكوين خادم AAA ل EAP-TLS. عندما يحاول العميل المصادقة، خاصة أثناء مرحلة تبادل الشهادات، يرسل العميل شهادة تتجاوز الحد الأقصى لحجم وحدة الإرسال (MTU) على وحدة التحكم اللاسلكية. ثم تقوم وحدة التحكم اللاسلكية 9800 بتقسيم هذه الحزمة الكبيرة إلى أجزاء وإرسال الأجزاء بشكل تسلسلي إلى خادم AAA. ومع ذلك، لا تصل هذه الأجزاء بالترتيب الصحيح في المضيف الفعلي، مما يؤدي إلى إسقاط الحزمة.

فيما يلي مسارات RA من وحدة التحكم اللاسلكية عند محاولة العميل الاتصال:
بدء تشغيل العميل الذي يدخل في حالة مصادقة L2 وعملية EAP

2023/04/12 16:51:27.606414 {wncd_x_r0-0}{1}: [dot1x] [19224]: (معلومات): [Client_MAC:capwap_9000004] يتم الآن إدخال حالة الطلب
2023/04/12 16:51:27.606425 {wncd_x_r0-0}{1}: [dot1x] [19224]: (معلومات): [000.000.000:capwap_9000004] إرسال حزمة EAPOL
2023/04/12 16:51:27.606494 {wncd_x_r0-0}{1}: [dot1x] [19224]: (معلومات): [Client_MAC:capwap_9000004] يرسل حزمة EAPOL - الإصدار : 3،نوع EAPOL : EAP، طول الحمولة : 1008، نوع EAP = EAP-TLS
2023/04/12 16:51:27.606496 {wncd_x_r0-0}{1}: [dot1x] [19224]: (معلومات): [Client_MAC:capwap_9000004] حزمة EAP - طلب، معرف : 0x25
2023/04/12 16:51:27.606536 {wncd_x_r0-0}{1}: [dot1x] [19224]: (معلومات): [Client_MAC:capwap_9000004] حزمة EAPOL مرسلة إلى العميل
2023/04/12 16:51:27.640768 {wncd_x_r0-0}{1}: [dot1x] [19224]: (معلومات): استلم [Client_MAC:capwap_9000004] حزمة EAPOL - الإصدار : 1،نوع EAPOL : EAP، طول الحمولة : 6، نوع EAP = EAP-TLS
2023/04/12 16:51:27.640781 {wncd_x_r0-0}{1}: [dot1x] [19224]: (معلومات): [Client_MAC:capwap_9000004] حزمة EAP - إستجابة، معرف : 0x25

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

2023/04/12 16:51:27.641094 {wncd_x_r0-0}{1}: [radius] [19224]: (معلومات): RADIUS: إرسال طلب الوصول إلى 172.16.26.235:1812 المعرف 0/6، len 552
2023/04/12 16:51:27.644693 {wncd_x_r0-0}{1}: [radius] [19224]: (معلومات): RADIUS: تم الاستلام من المعرف 1812/6 172.16.26.235:0، Access-Challenge، len 1141

في بعض الأحيان، قد يرسل العميل شهادته للمصادقة. إذا تجاوز حجم الحزمة وحدة الحد الأقصى للنقل (MTU)، فسيتم تجزئتها قبل إرسالها إلى المزيد.

2023/04/12 16:51:27.75836 {wncd_x_r0-0}{1}: [radius] [19224]: (معلومات): RADIUS: إرسال طلب الوصول إلى 172.16.26.235:1812 id 0/8، len 2048
2023/04/12 16:51:37.761885 {wncd_x_r0-0}{1}: [radius] [19224]: (معلومات): RADIUS: بدء مهلة 5 ثوان
2023/04/12 16:51:42.762096 {wncd_x_r0-0}{1}: [radius] [19224]: (معلومات): RADIUS: إعادة الإرسال إلى (172.16.26.235:1812،1813) للمعرف 0/8
2023/04/12 16:51:32.759255 {wncd_x_r0-0}{1}: [radius] [19224]: (معلومات): RADIUS: إعادة الإرسال إلى (172.16.26.235:1812،1813) للمعرف 0/8
2023/04/12 16:51:32.760328 {wncd_x_r0-0}{1}: [radius] [19224]: (معلومات): RADIUS: بدء مهلة 5 ثوان
2023/04/12 16:51:37.760552 {wncd_x_r0-0}{1}: [radius] [19224]: (معلومات): RADIUS: إعادة الإرسال إلى (172.16.26.235:1812،1813) للمعرف 0/8
2023/04/12 16:51:42.762096 {wncd_x_r0-0}{1}: [radius] [19224]: (معلومات): RADIUS: إعادة الإرسال إلى (172.16.26.235:1812،1813) للمعرف 0/8

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

2023/04/12 16:51:45.762890 {wncd_x_r0-0}{1}: [dot1x] [19224]: (معلومات): [Client_MAC:capwap_9000004] يتم الآن نشر EAPOL_START على العميل
2023/04/12 16:51:45.762956 {wncd_x_r0-0}{1}: [dot1x] [19224]: (معلومات): [client_mac:capwap_9000004] يدخل حالة الداخل
2023/04/12 16:51:45.762965 {wncd_x_r0-0}{1}: [dot1x] [19224]: (معلومات): [Client_MAC:capwap_9000004] يتم نشر !AUTH_ABORT على العميل
2023/04/12 16:51:45.762969 {wncd_x_r0-0}{1}: [dot1x] [19224]: (معلومات): [Client_MAC:capwap_9000004] يتم الآن إدخال حالة إعادة التشغيل

يتم إجراء هذه العملية في تكرار حلقي والعميل يعلق في مرحلة المصادقة فقط.

يظهر التقاط الحزمة المضمنة الملتقطة على وحدة التحكم اللاسلكية أنه بعد العديد من طلبات الوصول وعمليات تبادل التحديات مع وحدة الحد الأقصى للنقل (MTU) أقل من 1500 بايت، تقوم وحدة التحكم اللاسلكية بإرسال طلب وصول يتجاوز 1500 بايت، ويحتوي على شهادة العميل. تخضع هذه الحزمة الأكبر للتجزئة. ومع ذلك، لا توجد إستجابة لطلب الوصول هذا. تستمر وحدة التحكم اللاسلكية في إعادة إرسال هذا الطلب حتى يصل إلى الحد الأقصى لعدد مرات إعادة المحاولة، وبعد ذلك تتم إعادة تشغيل جلسة EAP-TLS. ويستمر تسلسل الأحداث هذا في التكرار، مما يشير إلى وجود حلقة متكررة ل EAP-TLS أثناء محاولة العميل المصادقة. يرجى الرجوع إلى عمليات التقاط الحزم المتزامنة من كل من وحدة التحكم اللاسلكية و ISE الموفرة أدناه للحصول على فهم أكثر وضوحا.

وحدة التحكم اللاسلكية EPC:

التقاط الحزمة على WLC

نلاحظ أن وحدة التحكم اللاسلكية تقوم بإرسال عدة طلبات مكررة لمعرف طلب وصول معين = 8

ملاحظة: في EPC، نلاحظ أيضا أن هناك طلب متكرر واحد لمعرفات أخرى. وهذا يثير السؤال: فهل هذه الازدواجية متوقعة؟ الإجابة على السؤال حول ما إذا كان هذا التكرار متوقعا هي "أجل". السبب هو أن الالتقاط قد تم أخذه من واجهة المستخدم الرسومية (GUI) لوحدة التحكم اللاسلكية مع تحديد الخيار "مستوى التحكم في الشاشة". ونتيجة لذلك، من الطبيعي ملاحظة العديد من مثيلات حزم RADIUS منذ توجيهها إلى وحدة المعالجة المركزية. في مثل هذه الحالات، يجب رؤية طلبات الوصول مع تعيين عناوين MAC للمصدر والوجهة على 00:00:00.

تم توجيه طلب وصول RADIUS إلى وحدة المعالجة المركزية على WLC

يجب إرسال طلبات الوصول ذات عناوين MAC المصدر والوجهة المحددة فقط من وحدة التحكم اللاسلكية.

تم إرسال طلب الوصول إلى RADIUS إلى خادم AAA

طلبات الوصول المعنية، المحددة بواسطة المعرف = 8، والتي يتم إرسالها عدة مرات ولم يتم الاطلاع على إستجابة لها من خادم AAA. بعد إجراء المزيد من التحقيقات، لاحظنا أنه بالنسبة لمعرف طلب الوصول=8، يحدث تجزئة UDP بسبب الحجم الذي يتجاوز MTU، كما هو موضح أدناه:

التجزئة التي تحدث على التقاط حزمة WLC

حزمة مجزأة - I

حزمة مجزأة - II

حزمة مجددة

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

عمليات ISE TCP Dumps

التقاط عند نهاية ISE

التقاط جانب Azure مع التحليل:

قام فريق Azure بإجراء التقاط على المضيف الفعلي داخل Azure. تشير البيانات الملتقطة على المحول vSwitch داخل مضيف Azure إلى أن حزم UDP تصل من التسلسل. نظرا لأن أجزاء UDP هذه ليست بالترتيب الصحيح، يتم تجاهل Azure. فيما يلي عمليات الالتقاط من كل من نهاية Azure ووحدة التحكم اللاسلكية، والتي تم التقاطها في وقت واحد لمعرف طلب الوصول = 255، حيث يكون إصدار الحزم غير المنتظم واضحا:
يعرض التقاط الحزمة المغلف (EPC) على وحدة التحكم اللاسلكية التسلسل الذي تغادر فيه الحزم المجزأة من وحدة التحكم اللاسلكية. 

تسلسل الحزم المجزأة على WLC

على المضيف الفعلي، لا تصل الحزم في التسلسل المناسب

التقاط عند نهاية Azure

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

الحل المقترح من نهاية وحدة التحكم اللاسلكية:

بدءا من الإصدار 17.11.1، نقوم بتنفيذ دعم الإطارات الكبيرة في حزم RADIUS/AAA. تتيح هذه الميزة لوحدة التحكم C9800 تجنب تجزئة حزم AAA، شريطة تعيين التكوين التالي على وحدة التحكم. يرجى ملاحظة أنه لتجنب تجزئة هذه الحزم بالكامل، من الضروري التأكد من أن كل خطوة على الشبكة، بما في ذلك خادم AAA، متوافقة مع حزم الإطارات Jumbo. بالنسبة إلى ISE، يبدأ دعم الإطارات كبيرة الحجم بالإصدار 3.1 وما بعده.
تكوين الواجهة على وحدة التحكم اللاسلكية:

C9800-CL(config)#interface C9800-CL(config-if) # mtu C9800-CL(config-if) # ip mtu [1500 to 9000]

تكوين خادم AAA على وحدة التحكم اللاسلكية:

C9800-CL(config)# aaa group server radius C9800-CL(config-sg-radius) # server name C9800-CL(config-sg-radius) # ip radius source-interface

فيما يلي نظرة موجزة على حزمة Radius عند تكوين وحدة الحد الأقصى للنقل (MTU) على 3000 بايت على وحدة تحكم شبكة محلية لاسلكية (WLC). تم إرسال الحزم التي يقل حجمها عن 3000 بايت بسلاسة تامة دون الحاجة إلى التجزئة:

التقاط الحزمة على WLC مع زيادة MTU

بإعداد التكوين بهذه الطريقة، ترسل وحدة التحكم اللاسلكية الحزم بدون تفتيتها، مرسلة إياها كما هي. ومع ذلك، نظرا لأن سحابة Azure لا تدعم إطارات jumbo، فلا يمكن تنفيذ هذا الحل.

الحل:

• من التقاط الحزم المغلف (EPC) لوحدة التحكم اللاسلكية، لاحظنا أنه يتم إرسال الحزم بالترتيب الصحيح. ومن ثم تقع على عاتق المضيف المتلقي مسؤولية إعادة تجميعها بشكل صحيح ومواصلة المعالجة، التي لا تحدث في هذه الحالة على جانب Azure.
• لمعالجة إصدار حزم UDP الخارجة عنenable-udp-fragment-reorderingالترتيب، يلزم تنشيط الخيار على Azure.
• يجب الاتصال بفريق دعم Azure للحصول على مساعدة في هذه المسألة. اعترفت Microsoft بهذه المشكلة.
  
  

  ملاحظة: يجب ملاحظة أن هذه المشكلة لا تقتصر على وحدة التحكم في الشبكة المحلية اللاسلكية (WLC). تمت مواجهة مشاكل مماثلة مع حزم UDP الخارجة عن الترتيب على خوادم RADIUS المختلفة، بما في ذلك ISE و Forti Authenticator وخوادم RTSP، وخاصة عندما تعمل داخل بيئة Azure.