Summary

  • تقترح مسودة فريق RADEXT توحيد حزمة RADIUS المسماة Protocol-Error، ذات الرمز 52، بعدما قدّمتها RFC 7930 بصفتها تجربة. وما زال سجل IANA يحيل الرمز إلى تلك الوثيقة.
  • يجب أن تحمل الرسالة Error-Cause وOriginal-Packet-Code. يربط الحقل الثاني العطل بنوع الطلب المعلّق الصحيح عندما تتشارك طلبات مختلفة رقم Identifier نفسه.
  • الخطأ مخصص للقفزة المجاورة. مع السببين 502 و505 ينبغي للوكيل تجربة اتصال آخر أو وجهة أخرى؛ وتحظر المسودة تكرار الطلب على الاتصال الذي أخفق.

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

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

يتألف عنوان العطل من حقلين إلزاميين. يصف Error-Cause السبب، ويحفظ Original-Packet-Code نوع الحزمة التي أطلقت الطلب. ويمكن لطلبات من أنواع مختلفة أن تحمل قيمة Identifier واحدة في RADIUS؛ لذلك لا يكفي الرقم وحده لمعرفة المعاملة المعنية. تنسخ الاستجابة رقم الطلب الأصلي، وعلى العميل أن يهمل رداً لا يطابق فيه رمز الحزمة الأصلية أي طلب لا يزال مفتوحاً. تشخيص صحيح ملصق بمعاملة أخرى قد يطلق إعادة إرسال خاطئة أو تفسيراً خاطئاً للمشترك.

العطل في الطريق يُعالجه من يملك الطريق

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

تسمي المسودة السببين 502، Request Not Routable (Proxy)، و505، Other Proxy Processing Error، بوصفهما مشكلتين في شبكة الوكلاء. ينبغي للوكيل عندئذ تجربة اتصال مختلف إلى الوجهة نفسها أو اختيار وجهة أخرى. ويمنع النص إعادة الطلب عبر الاتصال الذي أعاد الخطأ للتو. هذه الجملة القصيرة تفصل التعافي عن آلة توليد الحزم. إرسال الطلب بسرعة أكبر إلى الطريق المسدودة لا يفتحها. أما ترتيب البدائل وعدد المحاولات والمهلة الزمنية فتظل قرارات تشغيلية لم تحسمها المسودة بالكامل.

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

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

مسودة RADEXT · حالة Datatracker · RFC 7930 · سجل IANA