حين سمّت البتات الثمانية محاولات مختلفة: كيف ربط RADIUS الرد بطلب ما زال قائماً

الخلاصة

• لا يتجاوز حقل Identifier في RADIUS بايتاً واحداً، ودوره العثور على طلب معلّق محتمل. بعد ذلك يتحقق العميل من Response Authenticator باستخدام Request Authenticator ذي 16 بايتاً الخاص بذلك الطلب والسر المشترك في القفزة.
• تحتفظ إعادة الإرسال غير المعدلة إلى الخادم نفسه بالـIdentifier وRequest Authenticator ومنفذ المصدر. يعيد الخادم الرد المخزن من دون تنفيذ المصادقة مرة ثانية؛ أما تغيير أي Attribute فينشئ طلباً جديداً.

لم تكن القيم الـ256 سجلاً دائماً

يبدأ رأس RADIUS بحقول Code وIdentifier من ثماني بتات وLength وAuthenticator من 16 بايتاً، ثم Attributes. تبدو 256 قيمة قليلة أمام طلبات متزامنة، وفقد UDP، وخوادم بديلة، وحوارات مصادقة تمتد عبر عدة جولات.

ظهر أول معيار RADIUS في RFC 2058 في يناير 1997، ثم حل محله RFC 2138 في أبريل، قبل أن يرسخ RFC 2865 الصيغة الكلاسيكية سنة 2000. لم يصف أي منها الـIdentifier بأنه هوية عالمية؛ فهو يساعد على مطابقة الطلبات بالردود.

يوضح RFC 5080 عمر هذا الاسم. لا يعيد العميل استخدام القيمة مع عنوان ومنفذ مصدر معينين حتى يتلقى رداً صحيحاً أو تنتهي مهلة الطلب، ويستحسن توزيع القيم بأسلوب الأقل استخداماً في الآونة الأخيرة.

لذلك لا يعني الرقم 19 «عملية المصادقة التاسعة عشرة» إلى الأبد. إنه الاستخدام الحالي للرقم 19 داخل مجموعة طلبات ما زالت معلقة. بعد إغلاق النافذة يمكن أن يعود الرقم بمعنى آخر.

حمل الرد أثراً لا يمكن فصله عن السؤال

يحمل Access-Request قيمة Request Authenticator من 16 بايتاً. يجب تغييرها عند استخدام Identifier جديد، وينبغي أن تكون غير قابلة للتنبؤ وفريدة طوال عمر السر المشترك. قد يسمح تكرار القيمة مع السر نفسه بإعادة استعمال رد تم اعتراضه، وقد يتيح التنبؤ بقيمة مستقبلية إعداد رد مزور قبل وصول الطلب الحقيقي.

تنسخ رسائل Access-Accept وAccess-Reject وAccess-Challenge قيمة Identifier من الطلب. لكنها تحسب Response Authenticator على Code وIdentifier وLength وAttributes الخاصة بالرد، إضافة إلى Request Authenticator الأصلي والسر المشترك.

يستخدم العميل البايت القصير للعثور على طلب مرشح ما زال معلقاً، ثم يعيد الحساب بقيمة الـ16 بايتاً لذلك الطلب تحديداً. إذا وصل رد قديم يحمل الرقم نفسه لكنه يرتبط بـRequest Authenticator سابق، يفشل التحقق ويُهمَل بصمت.

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

إعادة الإرسال كانت استمراراً في التسليم

استخدم RADIUS الكلاسيكي UDP لأن قرار الدخول يفيد خلال ثوان، لا بعد تسليم موثوق يصل بعد دقائق. يحتفظ العميل بنسخة فوق طبقة النقل، ويدير المؤقتات، وقد يعيد الإرسال أو يجرب خادماً بديلاً.

إذا بقيت Attributes كما هي وأعيد الطلب إلى الخادم نفسه، يجب إبقاء Identifier وRequest Authenticator ومنفذ المصدر. الداتاغرام الثاني محاولة أخرى لإيصال السؤال نفسه، وليس سؤال مصادقة ثانياً.

أما تعديل Attribute واحد — كإضافة Event-Timestamp أو تغيير جواب المستخدم أو الخدمة المطلوبة — فيفرض Identifier وRequest Authenticator جديدين. قد يكون الشخص نفسه، لكن الادعاء المقدم للخادم تغير، ومن حق السياسة أن تصل إلى نتيجة مختلفة.

هذه الحدود القابلة للملاحظة تمنع عبارة «المحاولة نفسها» من التحول إلى تقدير بشري غير قابل للاختبار.

أعاد الخادم النتيجة ولم يعِد القرار

يلزم RFC 5080 خادم RADIUS باكتشاف Access-Request المكرر وبحفظ Access-Accept أو Access-Reject أو Access-Challenge الذي أرسله. إذا جاء التكرار بعد إصدار الرد، يعيد الخادم الرد الأصلي من دون معالجة الطلب مرة أخرى. وإذا وصل بينما الطلب الأول قيد التنفيذ، يتجاهله بصمت.

الغاية أوسع من توفير المعالج. قد تسجل المصادقة دخولاً، أو تزيد عداداً، أو تستهلك قيمة لمرة واحدة، أو تكتب في نظام خلفي. لا ينبغي لفقد رد واحد أن يحول أثراً واحداً إلى أثرين.

تتكون مطابقة الذاكرة من عنوان المصدر ومنفذه وIdentifier ومقبس الاستقبال وRequest Authenticator، وتعيش غالباً بين خمس وثلاثين ثانية. إذا تطابقت العناصر الأربعة الأولى واختلفت قيمة المصادق، تُبطل خانة الذاكرة القديمة. التشابه المرئي لا يساوي التكرار.

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

تغيير المحتوى أنهى صلاحية الجواب السابق

قد يبقى الطلب الأول قيد المعالجة بينما يرسل العميل طلباً معدلاً بمواد معاملة جديدة. يمكن أن يكون الرد المتأخر صحيحاً تماماً بالنسبة إلى Request Authenticator القديم، لكنه لم يعد جواب الطلب الحالي.

يعالج العميل أول رد صحيح لطلب ما زال معلقاً. بعد إغلاق الطلب تصبح الردود اللاحقة غير مطلوبة وتُهمَل. الصحة التشفيرية التاريخية لا تعيد الصلاحية الزمنية.

يوضح Access-Challenge الفرق في الحوار متعدد الجولات. قد يعيد الخادم State ويطلب جواباً إضافياً. يرسل NAS طلب Access-Request جديداً بـIdentifier وRequest Authenticator جديدين، ويعيد State مع جواب المستخدم. تصل State بين جولات الجلسة؛ لكنها لا تجعل كل الجولات معاملة واحدة.

قد تختلف سياسة الخادم الأساسي والبديل، فيصدر أحدهما Reject والآخر Accept. قاعدة أول رد صحيح تنظم قرار العميل، لكنها لا تزامن قواعد البيانات والسياسات. تلك مسؤولية المشغل.

لم يستطع Accept أن يخلق خدمة غير موجودة

ينص RFC 2865 على أن NAS يعامل Access-Accept كرفض إذا لم يستطع تقديم الخدمة المحددة فيه. لا تنشئ الرسالة VLAN أو مساراً أو بروتوكولاً غير متاح.

يثبت Response Authenticator، ضمن حدود بنيته التاريخية، أن الطرف الذي يعرف سر القفزة أجاب عن الطلب المعلق بهذه المحتويات. لا يثبت بمفرده هوية الإنسان بعيداً عن طريقة PAP أو CHAP أو EAP المحمولة في Attributes، ولا صحة السياسة، ولا تنفيذ المحاسبة، ولا مرور حركة الخدمة.

يبقى التنفيذ دليلاً محلياً لا يمكن للرد البعيد استبداله.

أعاد الوكيل بناء الثقة لكل قفزة

يتحقق وكيل RADIUS من رد الخادم البعيد بسر تلك العلاقة، ويحذف آخر Proxy-State أضافه، ويستعيد Identifier المتوقع من العميل السابق، ثم يحسب Response Authenticator جديداً بسر القفزة الصاعدة.

لا يحصل NAS على توقيع شامل من home server إلى الحافة. يحصل على إثبات من نظيره المباشر. تساعد Proxy-State الرد على الرجوع عبر السلسلة وتبقى مبهمة لمن لم ينشئها، لكنها ليست تفويضاً بالدخول.

لذلك لا يكفي سجل يقول «Identifier 19، Accept». يلزم تحديد القفزة والعناوين والمنافذ ومقبس الاستقبال ومدة التعليق وبصمة محمية لـRequest Authenticator وشكل الطلب وفعل ذاكرة التكرار ومسار الوكيل والأثر الذي نفذه NAS. يجب ألا يؤدي ذلك إلى تسجيل الأسرار أو بيانات الاعتماد الحساسة.

أمكن للمؤقتات أن تجمع آلاف العملاء في موجة واحدة

يوثق RFC 5080 عملاء يعيدون الإرسال كل ثانية أو أقل بلا تراجع ازدحام. بعد انقطاع كهربائي، قد تبدأ آلاف أجهزة NAS معاً، وتنتهي مؤقتاتها معاً، وتعيد الإرسال معاً، فتغرق خدمة المصادقة في لحظة التعافي.

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

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

نقل TLS موضع الحماية لاحقاً

وضع RFC 6614 RADIUS داخل TLS/TCP سنة 2012، لكنه أبقى آليات MD5 التاريخية داخل الحزمة واستخدم السر الثابت radsec لتلك الحسابات. حمى TLS الاتصال، وظلت القواعد القديمة داخل النفق.

عرّف RFC 9765 سنة 2025 ملف RADIUS/1.1 لقفزة تتفاوض عليه صراحة عبر ALPN فوق TLS 1.3 أو أحدث. عندئذ يختفي السر المشترك وحساب MD5، وتتحول مساحة الـ16 بايتاً إلى Token مبهم يتولى أيضاً وظيفة ربط الطلب بالرد بدلاً من Identifier.

هذه حدود المقال المنشور سابقاً عن RADIUS/1.1، وليست موضوع هذا المقال. لا يغير الملف RADIUS/UDP ولا يرقّي كل قفزات سلسلة الوكلاء. أهميته هنا محدودة: حتى حين تتولى طبقة النقل السرية والمصداقية، يبقى من الضروري تسمية السؤال المعلق بدقة.

وصف التاريخ ليس تزكية لـMD5

لا يجعل Response Authenticator الكلاسيكي MD5 خياراً حديثاً آمناً. ولا يثبت جودة السياسة أو اكتمال المحاسبة أو نزاهة كل وكيل أو تسليم الخدمة. تثبت سجلات RFC السلوك المحدد وتطوره، لا امتثال منتج أو نسبة الانتشار الحالية.

الدرس الأبقى هو حدود الاسم القصير. يعمل حين يبقى نطاقه وعمره وسياقه المركب معه. ويصبح مضللاً حين تحتفظ المؤسسة بالبتات الثمانية في أرشيف طويل وتفقد الحالة الحية التي منحتها معناها.