eapol_test عبر VPN: هل يحتاج تبادل RADIUS إلى الطبقة 2؟

اطلب منفذ محوّل في المختبر لتشغيل eapol_test وربما أسأت فهم الأداة. فالنظير وعميل RADIUS كلاهما داخل ذلك الملف التنفيذي الواحد، لذا فالمحادثة الوحيدة التي تغادر الجهاز هي تبادل RADIUS نفسه. والنفق الموجّه بين مضيف الاختبار وخادم المصادقة هو كل متطلبات الشبكة. أما مسار 802.1X الفيزيائي فهو شيء آخر قد تحتاج إلى اختباره، وليس هذا.

لماذا يدفع الاسم الناس إلى البحث عن منفذ محوّل

EAPOL هو صيغة الإطار التي يستخدمها الملتمِس والمحوّل على شبكة محلية، وقد استعارت الأداة الاسم لأنها نشأت من ذلك العالم. ما يُشحن هو برنامج اختبار يحمل آلة حالة النظير وعميل RADIUS في عملية واحدة، لذا لا يلتقي نصفا محادثة 802.1X أبدًا عبر سلك. الاسم تاريخ، وليس شرطًا طوبولوجيًا.

لا يزال الناس يطلبون المنفذ لأن البرنامج يقوم على سلوك المصادِق، وهذا يبدو كعتاد. فغراؤه يعيد إنتاج آلة حالة المصادِق، لذا يكتمل الاختبار دون وجود نقطة وصول في الغرفة؛ والملف التنفيذي المدمج يربط نظير EAP في wpa_supplicant بعميل RADIUS في hostapd. وإزالة المحوّل تزيل قفزة EAPOL، لا منطق المصادقة. وما يبقى هو تبادل بين عميل وخادم عبر مضيفَي IP.

تتبّع تبادل RADIUS واحدًا قفزة بقفزة

تتبّع محاولة واحدة وستجد المسار قصيرًا. فالنظير داخل eapol_test ينتج EAP-Response للطريقة التي أعددتها، وعميل RADIUS في العملية نفسها يضعها في Access-Request، حاملًا الحمولة في سمات EAP-Message إلى جانب Message-Authenticator. وتُوجَّه هذه الحزمة إلى الخادم على منفذ UDP 1812، وتغادر المضيف كأي حزمة IP أخرى، وهنا يأتي دور النفق. ويقيّمه الخادم وفق سياسته ووحدات طرقه، ثم يرد بـ Access-Challenge أو Access-Accept أو Access-Reject.

eapol_test -c peap-mschapv2.conf -a 198.51.100.20 -p 1812 \
  -s REPLACE_WITH_RADIUS_SECRET -t 30

يأخذ الملف التنفيذي عنوان الخادم والمنفذ والسر المشترك من سطر الأوامر، والطريقة وبيانات الاعتماد من كتلة إعداد على نمط wpa_supplicant. ولا شيء في ذلك الاستدعاء يعتمد على تجاور الطبقة 2: الوصول إلى -a يتم عبر التوجيه، ويكفي VPN يوجّهه. وإذا أسقط النفق الحزمة، فشل الاختبار تمامًا كما لو كان الخادم غير قابل للوصول على شبكة محلية مسطحة.

الملف التنفيذي وسياسة الخادم قائمتان مختلفتان

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

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

ما لا يغطيه النجاح بعد

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

السجل المفيد هو ما لاحظه الخادم والعملية كلٌّ على حدة: أي طريقة فُوّضت، وأين توقف التبادل، وما سجّله الخادم. أبقِ الأسرّة المشتركة والمفاتيح الخاصة خارج ذلك السجل.

قائمة تحقق قبل الاقتباس من النتيجة

قبل أن يتعامل أي شخص مع المخرجات كموافقة، أكّد أربعة أمور. البناء يتضمن الطريقة قيد الاختبار، ونقطة نهاية RADIUS والسر المشترك يخصان البيئة قيد الاختبار، وسياسة الخادم تسمح بهوية الاختبار هذه، ومسار الشبكة من الفئة نفسها التي يستخدمها عملاء الإنتاج. ثم سمِّ ما لم يلمسه التشغيل: نقطة الوصول والمحوّل وVLAN وتكامل المجمّع يحتاج كل منها سطرًا خاصًا في خطة الاختبار.

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