EAP عبر بوابة VPN: من ينهي الطريقة

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

مسارا مصادقة يبدوان متشابهين في السجل

في المسار الأول تجمع بوابة VPN اسم المستخدم وكلمة المرور وترسل طلب وصول RADIUS مع خاصية كلمة المرور. يقارنه خادم المصادقة بمخزون بيانات الاعتماد لديه ويجيب بالقبول أو الرفض. لا ينفذ العميل أي طريقة EAP أبدًا لأن شيئًا لم يطلب منه ذلك.

في المسار الثاني ينفذ العميل وخادم المصادقة طريقة EAP من طرف إلى طرف، وتمرر البوابة خصائص EAP-Message بينهما. لا تزال البوابة تنهي محادثة RADIUS الخارجية، لكن منطق الطريقة يقيم عند الطرفين.

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

أين تعمل الطريقة فعليًا

RFC 3579 يعرّف ترتيب التمرير: يحمل NAS حزم EAP في خصائص RADIUS ولا يحتاج إلى شيفرة خاصة بكل نوع من أنواع EAP. لهذا يمكن لبوابة أن تدعم PEAP وEAP-TLS دون تنفيذ أي منهما.

البوابة التي ترسل كلمة مرور لا تحمل PEAP، حتى لو كان الخادم الخلفي سيقبل PEAP من عميل آخر. تمكين PEAP في سياسة الخادم لا يضيف طريقة إلى عميل لم يعرض واحدة قط.

إعدادات مصادقة PPP تنتمي إلى خدمة PPP، ولا تعيد تهيئة كل مسار IPsec أو XAuth القديم الذي يستخدم خادم AAA نفسه بصمت، لذا قد يترك تغيير ينجح لنوع وصول واحد النوع الآخر دون مساس.

ما يجب أن يدعمه NAS

ينقل التمرير المتطلب من شيفرة الطريقة إلى دعم الحامل. يجب أن تكون البوابة قادرة على حمل EAP عبر بروتوكول VPN الخاص بها، وأن يكون عميل RADIUS عليها قادرًا على إرسال واستقبال خصائص EAP-Message بالأحجام المعنية.

في IKEv2 يكون EAP جزءًا من تدفق مصادقة معرّف، وتأتي فحوص هوية الخادم والثقة من ذلك التدفق. لا تنتقل تسمية PEAP المستعارة من نشر 802.1X تلقائيًا، لأن التفاوض حولها يختلف.

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

اقرأ محاولة واحدة قبل تغيير السياسة

التقط محاولة معتمدة واحدة عند البوابة وعند خادم المصادقة. ابحث عن خصائص EAP-Message في طلب RADIUS. وجودها يخبرك أن مسار التمرير قيد الاستخدام؛ وغيابها يشير إلى تبادل بيانات اعتماد.

على بوابة Linux يُظهر التقاط على منفذ RADIUS الخصائص الموجودة على السلك:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

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

خطط للترحيل كتغيير واحد من طرف إلى طرف

تغيير الطريقة يعني تغيير تهيئة العميل ودعم الحامل في البوابة وسياسة الطريقة في الخادم ومخزون بيانات الاعتماد معًا. نفذها بهذا الترتيب واحتفظ بمسار عامل حتى يُثبت الجديد. التغيير على جانب الخادم وحده تخمين، وعادة يكسر العملاء الذين كانوا يعملون. جهّز التغيير على هوية اختبار واحدة قبل لمس المجموعة.

سجّل التركيبة التي تعمل: بروتوكول VPN وحامل EAP وطريقة النظير وطريقة الخادم ونوع بيانات الاعتماد وفحص هوية الخادم.

أبقِ AAA لتسجيل الدخول الإداري منفصلًا عن مصادقة VPN ما لم تتضمن المهمة كليهما صراحة. فالتغيير المقصود للوصول عن بعد يجب ألا يزيل قدرتك على إدارة الجهاز الذي ينهيه.