الخلاصة

  • يحصر draft-ietf-radext-radiusdtls-bis-18 إثبات الحياة في اتصال بعينه والطرف الموجود في القفزة التالية؛ فالوكيل يحجب حالة النطاقات وخوادم الأصل ومخازن بيانات الاعتماد الواقعة خلفه.
  • حالة TLS/DTLS ورد Status-Server أدلة صحيحة لكنها محدودة. اختيار مسار realm وإعادة الإرسال وقرار التفويض وتنفيذ NAS والنتيجة التي يراها المستخدم تحتاج سلسلة مستقلة.

تبدأ المشكلة من كلمة «الخادم». يرسل جهاز الوصول Access-Request إلى وكيل اتحاد. بالنسبة إلى الجهاز، الوكيل خادم RADIUS. وبعد أن يقرأ الوكيل جزء realm من اسم المستخدم ويختار الوجهة، يصبح هو نفسه عميلًا أمام home server. وقد توجد بينهما عقد أخرى أو مخزن اعتماد مستقل لكل مؤسسة.

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

يضع القسم 3.8 من المراجعة 18 هذه الحدود داخل آلية التشغيل. يجب على تطبيق RadSec جمع حالة TCP أو TLS أو DTLS مع مراقب طبقة التطبيق الوارد في RFC 3539. ولا يصنّف اتصالًا بأنه down إلا إذا قالت مكدسة الشبكة إنه لم يعد صالحًا، أو لم يعد D(TLS) يقدم اتصالًا قابلًا للاستخدام، أو صنّفه المراقب التطبيقي بذلك.

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

هذا يمنع توسيع عطل محلي. وهو يمنع أيضًا الاستدلال العكسي: نجاح اتصال واحد ليس شهادة لبقية الاتصالات أو لكل النطاقات التي يخدمها الوكيل.

يوضح RFC 5997 اختصاص Status-Server. لا يجوز لخادم RADIUS أو وكيله تمرير هذه الحزمة. يصل الرد من عنوان IP والمنفذ المستهدفين فقط. ولأن الخادم لا يفحص User-Name كي يرسل الفحص إلى realm بعينه، لا يمكن استخدام الرد لاستنتاج إمكان الوصول إلى ذلك النطاق.

عدم التمرير هو ما يجعل الفحص مفيدًا. إذا سكت Access-Request ورد Status-Server، يستطيع المشغّل فصل حياة الوكيل الأول عن صمت ما بعده. لكنه لا يعرف من الفحص وحده إن كان الخلل في قاعدة التوجيه أو الوصلة التالية أو home server أو مخزن بيانات الاعتماد.

تلزم المراجعة عملاء RadSec بتنفيذ الفحص والخوادم بالإجابة عنه. وبسبب اقتصار Identifier في RADIUS على 256 قيمة متزامنة، توصي بحجز القيمة صفر في كل اتصال للفحص. وقد تعجّل TCP keepalive أو DTLS heartbeat إشعار فشل النقل. لكنها تظل تقيس اتصالًا إلى طرف مجاور، لا اكتمال مصادقة مستخدم.

ينشأ عن خلط النطاقين خطآن متعاكسان.

الأول هو failover مبكر. يتأخر خادم نطاق واحد، فيعلن NAS موت الوكيل كله وينقل كل النطاقات إلى وكيل احتياطي. تنتقل حركة سليمة، وتُنشأ اتصالات جديدة، ويرث الاحتياطي حمل مشكلة تخص فرعًا واحدًا. يشير RFC 3539 إلى أن العميل الموجود قبل وكيل لا يملك معلمات النقل من الطرف إلى الطرف اللازمة لاستنتاج توقيت failover من اتصاله المحلي.

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

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

حتى الحماية المشفرة لها نطاق واضح. يثبت TLS أو DTLS هوية طرف RadSec المجاور ويحمي ذلك المقطع. وتحذر الوثيقة من أن وكيلًا وسيطًا قد يمرر الحزمة بعد ذلك عبر RADIUS/UDP المكشوف. لا يملك العميل الأول وسيلة بروتوكولية لفرض النقل الآمن على السلسلة كلها. إذا كانت السرية الكاملة مطلوبة، فعلى المؤسسة أن تضبط كل وسيط.

تكشف حدود النقل أيضًا مالك إعادة الإرسال. يعتمد RADIUS/TCP وRADIUS/TLS على نقل موثوق، فلا يعيدان حزمة RADIUS على الاتصال نفسه. أما RADIUS/UDP وRADIUS/DTLS فيحتاجان إعادة إرسال تطبيقية. إذا استقبل الوكيل من نقل غير موثوق وأرسل عبر نقل موثوق، فعليه ألا يمرر النسخ المكررة الواردة. وإذا استقبل عبر الموثوق وأرسل عبر غير الموثوق، يصبح الوكيل مسؤولًا عن المحاولات التالية.

عندما يغلق الاتصال الموثوق الوارد، لا يبقى مكان صالح لتسليم الرد، فيجب وقف إعادة الإرسال في الجهة الأخرى. وكذلك عندما يعيد العميل استخدام Identifier ويشير ضمنيًا إلى التخلي عن الطلب القديم. لذلك قد يكون العميل قد توقف بينما ما زال الوكيل يحتفظ بمؤقت، أو يكون الوكيل سليمًا والخادم الخلفي مثقلًا، أو يكون الخادم قد نفذ الطلب وردّه متأخرًا. timeout واحد لا يحدد أيًا منها.

تظهر الكلفة في محاسبة RADIUS. توصي المراجعة باستخدام Event-Timestamp ثابت يعبّر عن وقت الحدث الحقيقي، وتحظر تحديثه في إعادة الإرسال. أما تغيير Acct-Delay-Time فينشئ حزمة جديدة لمعلومة شبه مطابقة، وربما Identifier جديدًا. عند الانتقال من TLS إلى UDP، قد يبدأ الوكيل سلسلة إعادة إرسال مستقلة لكل نسخة بينما يعالج الخادم البطيء الأولى بالفعل.

يعرض الملحق A.2 حدثًا واحدًا يتحول إلى المعرفات 101 و102 و103 لدى الخادم. يساعد وقت الحدث الثابت على اكتشاف التكرار، لكنه ليس معرف معاملة عالميًا ولا يضمن التنفيذ مرة واحدة. يلزم ربط الحدث بالحزمة والقفزة ومالك المؤقت وقرار الخادم والكتابة النهائية.

ولا تعني كل علة تحقق سلوكًا عدائيًا. يشرح الملحق A.1 سباقًا يعاد فيه استخدام Identifier بعد انتهاء مهلة الطلب. يصل رد قديم بعد أن بدأ طلب جديد بالقيمة نفسها، فيفشل Response Authenticator عند مقارنته بالجديد. ينبغي إسقاط الرد مع إبقاء الاتصال. فشل حزمة وفشل اتصال وسوء سلوك الطرف ثلاثة استنتاجات منفصلة.

هذه المادة ما تزال Internet-Draft عاملة في RADEXT. سُجلت المراجعة 18 في 30 سبتمبر 2026، والمستوى المقصود Proposed Standard، وتنتهي في 3 أبريل 2027، ولا تحمل رقم RFC. ولن يصبح اقتراح إلغاء RFC 6614 وRFC 7360 التجريبيين نافذًا إلا بعد الموافقة والنشر. ولا يثبت السجل تبنيًا أو تشغيلًا بينيًا أو حادثة لدى شبكة بعينها.

لذلك تبدأ العبارة التشغيلية الآمنة بحد صغير: استجاب طرف RadSec هذا، عبر هذا الاتصال، في هذا الوقت. ثم يضاف realm المطلوب والمسار المختار والطرف الخلفي ونتيجة الاعتماد والتفويض وتنفيذ NAS وتجربة المستخدم. ينسق المعيار القفزة المشتركة؛ ولا يمنح نجاحها سلطة رمزية على واقع لا تراه.

المصادر