أستكشاف أخطاء عمليات تنفيذ وسلوك تجزئة EAP وإصلاحها

المقدمة

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

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• بروتوكولات EAP و EAP-TLS
• تكوين محرك خدمات الهوية من Cisco (ISE)
• CLI تشكيل من cisco مادة حفازة مفتاح

من الضروري فهم EAP و EAP-TLS فهما جيدا من أجل فهم هذه المقالة.

المكونات المستخدمة

لا يقيد هذا وثيقة إلى خاص جهاز وبرمجية صيغة.

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

معلومات أساسية

تم تخصيص أقسام من هذا المستند للتغطية في هذه المجالات:

• سلوك خوادم المصادقة والتفويض والمحاسبة (AAA) عند إرجاع شهادة الخادم لجلسة عمل أمان طبقة النقل - بروتوكول المصادقة المتوسع (EAP-TLS).
• سلوك المتضامنين عند إرجاع شهادة العميل لجلسة EAP-TLS.
• قابلية التشغيل البيني عند إستخدام كل من ملتمس Microsoft Windows الأصلي ومدير الوصول إلى الشبكة (NAM) من Cisco AnyConnect.
• التجزئة في IP و RADIUS و EAP-TLS وعملية إعادة التجميع التي يتم تنفيذها بواسطة أجهزة الوصول إلى الشبكة.
• سمة وحدة الإرسال القصوى المؤطرة (MTU) ل RADIUS.
• سلوك خوادم AAA عند إجراء تجزئة لحزم EAP-TLS.

تم إرجاع سلسلة الشهادات بواسطة الخادم

يرجع خادم AAA (خادم التحكم في الوصول (ACS) و ISE) دائما السلسلة الكاملة لحزمة EAP-TLS مع Server Hello وشهادة الخادم:

يتم إرجاع شهادة هوية ISE (الاسم الشائع (CN)=lise.example.com) مع المرجع المصدق (CA) الذي وقع على CN=win2012،dc=example،dc=com. ولا يختلف السلوك بالنسبة لكل من ACS و ISE.

سلسلة الشهادات التي تم إرجاعها من قبل المتلقي

ملتمس Microsoft Windows الأصلي

يتم تكوين طالب Microsoft Windows 7 الأصلي لاستخدام EAP-TLS، مع تحديد الشهادة البسيط أو بدونه، ولا يرسل السلسلة الكاملة لشهادة العميل. يحدث هذا السلوك حتى عندما تكون شهادة العميل موقعة من مرجع مصدق (CA) مختلف (سلسلة مختلفة) عن شهادة الخادم.

يرتبط هذا المثال بشهادة Server Hello المقدمة في لقطة الشاشة السابقة. بالنسبة لهذا السيناريو، يتم توقيع شهادة ISE من قبل CA باستخدام اسم موضوع، CN=win2012،dc=example،dc=com، ولكن شهادة المستخدم المثبتة في مخزن Microsoft موقعة من قبل CA آخر، CN=CA،C=PL،S=Cisco CA،L=Cisco CA، o=Cisco CA.

ونتيجة لذلك، يستجيب طالب Microsoft Windows لشهادة العميل فقط. CA الذي يوقع عليه (CN=CA،S=PL،S=Cisco CA، L=Cisco CA، o=Cisco CA) غير مرفق.

وبسبب هذا السلوك، من المحتمل أن تواجه خوادم AAA مشاكل عند التحقق من شهادات العميل. يتعلق المثال بنظام التشغيل Microsoft Windows 7 SP1 Professional.

الحل

يجب تثبيت سلسلة شهادات كاملة على مخزن شهادات ACS و ISE (كافة شهادات عميل توقيع CA و CA الفرعي).

يمكن اكتشاف مشكلات التحقق من صحة الشهادة بسهولة على ACS أو ISE. يتم تقديم المعلومات حول الشهادة غير الموثوق بها وتقارير ISE:

12514 EAP-TLS failed SSL/TLS handshake because of an unknown CA in the client
certificates chain

لا يمكن بسهولة اكتشاف المشاكل المتعلقة بالتحقق من صحة الشهادة على مقدم الطلب. عادة، يستجيب خادم AAA لجلسة عمل EAP التي تخلت عنها نقطة النهاية.

AnyConnect NAM

لا تحتوي AnyConnect NAM على هذا الحد. وفي السيناريو نفسه، ترفق السلسلة الكاملة لشهادة العميل (يرفق المرجع المصدق الصحيح).

عميل Microsoft Windows الأصلي مع AnyConnect NAM

عندما تكون كلتا الخدمتين قيد التشغيل، تكون الأولوية ل AnyConnect NAM. حتى عندما لا تعمل خدمة NAM، فإنها تظل متصلة ب Microsoft Windows API وتعيد توجيه حزم EAP، مما قد يسبب مشاكل للمطالب الأصلي ل Microsoft Windows.

وإليكم مثالا على مثل هذا الفشل.

يمكنك تمكين التتبع على Microsoft Windows باستخدام هذا الأمر:

C:\netsh ras set tracing * enable

تظهر الآثار (c:\windows\trace\svchost_RASTLS.LOG):

[2916] 09-14 21:29:11:254: >> Received Request (Code: 1) packet: Id: 55, Length:
6, Type: 13, TLS blob length: 0. Flags: S
[2916] 09-14 21:29:11:254: << Sending Response (Code: 2) packet: Id: 55, Length:
105, Type: 13, TLS blob length: 95. Flags: L
[1804] 09-14 21:29:11:301: >> Received Request (Code: 1) packet: Id: 56, Length:
1012, Type: 13, TLS blob length: 2342. Flags: LM
[1804] 09-14 21:29:11:301: << Sending Response (Code: 2) packet: Id: 56, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:348: >> Received Request (Code: 1) packet: Id: 57, Length:
1008, Type: 13, TLS blob length: 0. Flags: M
[1804] 09-14 21:29:11:348: << Sending Response (Code: 2) packet: Id: 57, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:363: >> Received Request (Code: 1) packet: Id: 58, Length:
344, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:363: << Sending Response (Code: 2) packet: Id: 58, Length:
1492, Type: 13, TLS blob length: 1819. Flags: LM
[3084] 09-14 21:31:11:203: >> Received Request (Code: 1) packet: Id: 122, Length:
6, Type: 13, TLS blob length: 0. Flags: S
[3084] 09-14 21:31:11:218: << Sending Response (Code: 2) packet: Id: 122, Length:
105, Type: 13, TLS blob length: 95. Flags: L
[3420] 09-14 21:31:11:249: >> Received Request (Code: 1) packet: Id: 123, Length:
1012, Type: 13, TLS blob length: 2342. Flags: LM
[3420] 09-14 21:31:11:249: << Sending Response (Code: 2) packet: Id: 123, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:281: >> Received Request (Code: 1) packet: Id: 124, Length:
1008, Type: 13, TLS blob length: 0. Flags: M
[3420] 09-14 21:31:11:281: << Sending Response (Code: 2) packet: Id: 124, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:281: >> Received Request (Code: 1) packet: Id: 125, Length:
344, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:296: << Sending Response (Code: 2) packet: Id: 125, Length:
1492, Type: 13, TLS blob length: 1819. Flags: LM

الحزمة الأخيرة هي شهادة عميل (EAP-TLS جزء 1 بحجم EAP 1492) مرسلة من قبل طالب Microsoft Windows الأصلي. لسوء الحظ، لا يعرض Wireshark هذه الحزمة:

وهذه الحزمة لا يتم إرسالها حقا؛ وكان آخر جزء ثالث من EAP-TLS يحمل شهادة خادم.

تم إستهلاكه من قبل وحدة AnyConnect NAM المتصلة بواجهة برمجة تطبيقات Microsoft Windows.

ولهذا السبب لا يوصى باستخدام AnyConnect مع طالب Microsoft Windows الأصلي.

عند إستخدام أي خدمات AnyConnect، يوصى باستخدام NAM أيضا (عند الحاجة إلى خدمات 802.1x)، وليس ملتمس Microsoft Windows الأصلي.

تشظية

من المحتمل أن يحدث التجزئة على طبقات متعددة:

• IP
• أزواج قيمة سمة RADIUS (AVP)
• EAP-TLS

محولات Cisco IOS^® ذكية جدا. يمكنهم فهم تنسيقات EAP و EAP-TLS. على الرغم من أن المحول غير قادر على فك تشفير نفق TLS، فإنه مسؤول عن التجزئة، وتجميع وإعادة تجميع حزم EAP عند التضمين في بروتوكول المصادقة المتوسع عبر LAN (EAPoL) أو RADIUS.

لا يدعم بروتوكول EAP التجزئة. فيما يلي مقتطف من RFC 3748 (EAP):

"لا يتم دعم التجزئة داخل EAP نفسه؛ ومع ذلك، يمكن أن تدعم أساليب EAP الفردية هذا الأمر.

EAP-TLS هو مثال. فيما يلي مقتطف من RFC 5216 (EAP-TLS)، القسم 2.1.5 (التجزئة):

"عندما يستلم نظير EAP-TLS حزمة EAP-Request مع مجموعة بت M، يجب أن يستجيب مع EAP-Response باستخدام EAP-type=EAP-TLS وبدون بيانات.

هذا يعمل كجذام. يجب أن ينتظر خادم EAP حتى يستلم إستجابة EAP قبل إرسال جزء آخر.

تصف الجملة الأخيرة ميزة مهمة للغاية لخوادم AAA. ويجب عليهم انتظار ACK قبل أن يتمكنوا من إرسال جزء EAP آخر. وتستخدم قاعدة مماثلة للمطالب:

"يجب أن ينتظر نظير EAP حتى يستلم طلب EAP قبل إرسال جزء آخر."

التجزئة في طبقة IP

يمكن أن يحدث التجزئة فقط بين جهاز الوصول إلى الشبكة (NAD) وخادم AAA (IP/UDP/RADIUS المستخدم كنقل).

ويحدث هذا الموقف عندما يحاول NAD (محول Cisco IOS) إرسال طلب RADIUS الذي يحتوي على حمولة EAP، والتي تكون أكبر من MTU للواجهة:

معظم إصدارات Cisco IOS ليست ذكية بشكل كاف ولا تحاول تجميع حزم EAP المستلمة عبر EAPoL، وتجميعها في حزمة RADIUS التي يمكن أن تلائم في وحدة الحد الأقصى للنقل (MTU) للواجهة المادية تجاه خادم AAA.

خوادم AAA أكثر ذكاء (كما هو موضح في الأقسام التالية).

التجزئة في RADIUS

هذا ليس حقا أي نوع من التجزئة. طبقا ل RFC 2865، يمكن أن يكون لسمة RADIUS واحدة ما يصل إلى 253 بايت من البيانات.ولهذا السبب، فإن حمولة EAP تنتقل دائما في سمات RADIUS متعددة لرسالة EAP:

يعاد تجميع سمات رسالة EAP هذه ويفسرها Wireshark (تكشف سمة المقطع الأخير حمولة حزمة EAP بأكملها).

رأس الطول في حزمة EAP يساوي 1،012، ويتطلب أربعة RADIUS AVPs لنقله.

التجزئة في EAP-TLS

من لقطة الشاشة نفسها، يمكنك أن ترى ما يلي:

• طول حزمة EAP هو 1،012
• يبلغ طول EAP-TLS 2،342

وهذا يشير إلى أنها أول جزء من EAP-TLS ويتوقع المطالب المزيد، والذي يمكن تأكيده إذا فحصت علامات EAP-TLS:

يحدث هذا النوع من التجزئة غالبا في:

• تحدي الوصول إلى RADIUS الذي يتم إرساله بواسطة خادم AAA، والذي يحمل طلب EAP مع شهادة خادم طبقة مآخذ التوصيل الآمنة (SSL) مع السلسلة بأكملها.
• يرسل RADIUS Access-Request بواسطة NAD، الذي يحمل إستجابة EAP مع شهادة عميل SSL مع السلسلة بأكملها.

تأكيد جزء EAP-TLS

وكما أوضح سابقا، يجب الاعتراف بكل جزء من EAP-TLS قبل إرسال الأجزاء اللاحقة.

وفيما يلي مثال (التقاط الحزم ل EAPoL بين المتلقي و NAD):

ترجع إطارات EAPoL وخادم AAA شهادة الخادم:

• يتم إرسال هذه الشهادة في جزء EAP-TLS (الحزمة 8).
• يتعرف الطالب على هذا الجزء (الحزمة 9).
• ويرسل الجزء الثاني من EAP-TLS بواسطة NAD (الحزمة 10).
• يتعرف الطالب على هذا الجزء (الحزمة 11).
• تتم إعادة توجيه الجزء الثالث من EAP-TLS بواسطة NAD (الحزمة 12).
• وليس من الضروري أن يعترف الملتمس بذلك؛ بدلا من ذلك، فإنه يمضي مع شهادة العميل التي تبدأ في الحزمة 13.

فيما يلي تفاصيل الحزمة 12:

يمكنك أن ترى أن Wireshark أعاد تجميع الحزم 8، 10، و 12.

وحجم أجزاء EAP هو 1،002 و 1،002 و 338، مما يجعل الحجم الإجمالي لرسالة EAP-TLS يبلغ 2342.

يتم الإعلان عن إجمالي طول رسالة EAP-TLS في كل جزء. ويمكن تأكيد ذلك إذا قمت بفحص حزم RADIUS (بين NAD وخادم AAA):

يحمل حزم RADIUS أرقام 4 و 6 و 8 هذه الأجزاء الثلاثة من EAP-TLS. ويتم الاعتراف بالجزأين الأولين.

يستطيع Wireshark تقديم المعلومات حول أجزاء EAP-TLS (الحجم: 1002 + 1002 + 338 = 2342).

كان هذا السيناريو والمثال سهلا. لم يكن محول Cisco IOS بحاجة إلى تغيير حجم جزء EAP-TLS.

إعادة تجميع أجزاء EAP-TLS بحجم مختلف

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

في مثل هذا السيناريو، يقوم محول Cisco IOS بتجميع وإعادة تجميع أجزاء EAP-TLS ويغير أحجام أجزاء EAP-TLS.

وفيما يلي مثال على رسالة EAP كبيرة الحجم مرسلة من خادم AAA (شهادة خادم SSL):

1. يجب أن يرسل خادم AAA رسالة EAP-TLS مع شهادة خادم SSL. ويبلغ الحجم الإجمالي لحزمة EAP تلك 3،000. بعد تضمينها في RADIUS Access-Challenge/UDP/IP، فإنها لا تزال أقل من AAA Server interface MTU. يتم إرسال حزمة IP واحدة مع سمات رسالة EAP ل 12 RADIUS. لا يوجد تجزئة IP أو EAP-TLS.
   
   
2. يتلقى محول Cisco IOS هذه الحزمة، ويفصل بينها، ويقرر أن EAP يحتاج أن يكون أرسلت عن طريق EAPoL إلى الطالب. بما أن EAPoL لا يدعم التجزئة، فيجب على المحول إجراء تجزئة EAP-TLS.
   
   
3. يقوم محول Cisco IOS بتجهيز أول جزء من EAP-TLS يمكن وضعه في وحدة الحد الأقصى للنقل (MTU) للواجهة باتجاه الموجه (1500).
   
   
4. يتم تأكيد هذه القطعة بواسطة الطالب.
   
   
5. يتم إرسال جزء EAP-TLS آخر بعد تلقي الإقرار.
   
   
6. يتم تأكيد هذه القطعة بواسطة الطالب.
   
   
7. يتم إرسال الجزء الأخير من EAP-TLS بواسطة المحول.

ويكشف هذا السيناريو عن ما يلي:

• في بعض الظروف، يجب أن يقوم NAD بإنشاء أجزاء EAP-TLS.
• ويضطلع المعهد الوطني لإزالة الألغام بمسؤولية إرسال/إقرار تلك الأجزاء.

وقد يحدث نفس الموقف لمطلب متصل عبر إرتباط يدعم إطارات Jumbo بينما يحتوي خادم AAA على وحدة الحد الأقصى للنقل (MTU) أصغر (ثم يقوم محول Cisco IOS بإنشاء أجزاء EAP-TLS عندما يرسل حزمة EAP نحو خادم AAA).

سمة RADIUS Framed-MTU

بالنسبة ل RADIUS، هناك سمة MTU ذات إطار محدد في RFC 2865:

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

لا يحترم ISE التلميح. لا تؤثر قيمة وحدة الحد الأقصى للنقل (MTU) التي تم إرسالها بواسطة NAD في طلب الوصول على التجزئة التي تم إجراؤها بواسطة ISE.

لا تسمح محولات Cisco IOS المتعددة الحديثة بإجراء تغييرات على وحدة الحد الأقصى للنقل (MTU) لواجهة الإيثرنت باستثناء إعدادات الإطارات كبيرة الحجم التي تم تمكينها بشكل عام على المحول. يؤثر تكوين الإطارات كبيرة الحجم على قيمة سمة Framed-MTU التي يتم إرسالها في طلب وصول RADIUS. على سبيل المثال، تقوم بضبط:

Switch(config)#system mtu jumbo 9000

هذا يجبر المفتاح أن يرسل Framed-MTU = 9000 في كل RADIUS منفذ يطلب. نفس الشيء بالنسبة لوحدة الحد الأقصى للنقل (MTU) للنظام بدون إطارات ضخمة:

Switch(config)#system mtu 1600

وهذا يفرض على المحول إرسال وحدة الحد الأقصى للنقل (MTU) في إطار FRAMED = 1600 في جميع طلبات وصول RADIUS.

لاحظ أن محولات Cisco IOS الحديثة لا تسمح لك بتقليل قيمة وحدة الحد الأقصى للنقل (MTU) للنظام إلى أقل من 1500.

خوادم AAA وسلوك المكمل عند إرسال أجزاء EAP

محرك خدمات كشف الهوية (ISE)

يحاول ISE دائما إرسال أجزاء EAP-TLS (عادة ما يكون Server Hello with Certificate) التي يبلغ طولها 1002 بايت (على الرغم من أن الجزء الأخير يكون عادة أصغر).

وهو لا يفي بالإطار RADIUS-MTU. لا يمكن إعادة تكوينه لإرسال أجزاء EAP-TLS أكبر.

خادم نهج شبكة Microsoft (NPS)

من الممكن تكوين حجم أجزاء EAP-TLS إذا قمت بتكوين سمة Framed-MTU محليا على NPS.

حدث رغم أن المقال تكوين حجم حمولة EAP على Microsoft NPS يشير إلى أن القيمة الافتراضية لوحدة الحد الأقصى للنقل (MTU) في إطار لخادم NPS RADIUS هي 1500، فقد أظهر مختبر مركز المساعدة التقنية (TAC) من Cisco أنه يرسل 2000 مع الإعدادات الافتراضية (التي تم تأكيدها على مركز بيانات Microsoft Windows 2012).

وقد تم إختبار أن الإعداد Framed-MTU محليا وفقا للدليل المذكور سابقا يتم إحترامه من قبل NPS، ويقسم رسائل EAP إلى أجزاء من حجم معين في Framed-MTU، ولكن لا يتم إستخدام سمة Framed-MTU المستلمة في Access-Request (نفس الموجود على ISE/ACS).

تعيين هذه القيمة هو حل بديل صالح لإصلاح المشاكل في المخطط مثل هذا:

مصدر [MTU 1500] — — [MTU 9000]محول [MTU 9000] — [MTU 9000]مصادر الشبكة

لا تسمح لك المحولات حاليا بتعيين وحدة الحد الأقصى للنقل (MTU) لكل منفذ؛ ل 6880 مفتاح، أضفت هذا سمة مع cisco بق id CSCuo26327 - 802.1x EAP-TLS لا يعمل على FEX مضيف ميناء.

AnyConnect

يرسل AnyConnect أجزاء EAP-TLS (عادة شهادة العميل) التي يبلغ طولها 1486 بايت. لحجم القيمة هذا، يكون إطار الإيثرنت 1500 بايت. آخر جزء هو عادة أصغر.

ملتمس Microsoft Windows الأصلي

يرسل Microsoft Windows أجزاء EAP-TLS (عادة شهادة العميل) التي يبلغ طولها 1،486 أو 1،482 بايت. لحجم القيمة هذا، يكون إطار الإيثرنت 1500 بايت. آخر جزء هو عادة أصغر.

معلومات ذات صلة

• تكوين المصادقة المستندة إلى المنفذ IEEE 802.1x
• الدعم التقني والمستندات - Cisco Systems