الخلاصة

  • تطلب RFC 3539 من وكلاء وخوادم AAA الاستعداد لوصول نسخة مكررة عبر أي اتصال. قد تسبق النسخة البديلة الطلب الأصلي، ولا يعني فشل الاتصال أن المعاملة القديمة انقضت.
  • في مصادقة تعتمد على حالة سابقة، قد يمنح خادم أول Accept ثم يمنح خادم آخر Reject للنسخة المكررة. تعريف المعاملة، والتصرف في التكرار، واختيار العميل، وتنفيذ NAS، وتسوية المحاسبة، والنتيجة التي رآها المستخدم إيصالات منفصلة.

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

نشرت RFC 3539 في يونيو 2003 بوصفها Proposed Standard لملف نقل Authentication, Authorization and Accounting. لا تسجل الوثيقة حادثة لدى مشغل أو منتج معين. أهميتها هنا أنها تحدد متى تتوقف شهادة النقل: نجاح التحويل لا يوقع على قرار التفويض ولا على نتيجة الدخول.

الاتصال قد يموت قبل أن تموت المعاملة

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

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

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

الخلط بين الخطين يسمح لعبارة «تم التحويل» بأن تتحول خطأ إلى «لم يعد هناك سوى قرار واحد».

رسالة الحراسة تقيس النظير المباشر

تفرض RFC 3539 على بروتوكولات AAA دعم watchdog في طبقة التطبيق لكشف أعطال النقل ووظائف التطبيق بسرعة أكبر. صُممت الرسالة لاختبار النظير المباشر، لا الخوادم وقواعد البيانات الكامنة خلفه، وليست نبضة قلب لعنقود كامل.

تُعد أي AAA Response من النظير دليلاً على بقائه. لكن غياب الرد على طلب عادي لا يكفي للحكم بأنه Down، لأن التأخير قد يقع لدى وكيل أو خادم تالٍ. في الخوارزمية الموصوفة، يصبح فشل رد watchdog هو الحد الذي يبرر الانتقال الخاص بعطل النظير.

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

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

لا يوجد رقم أخضر يلغي الانتظار والتكرار معاً. مالك المؤقت يختار أين تُدفع كلفة عدم اليقين.

الطابور يعرف ما لم يستلمه محلياً فقط

يحتفظ العميل أو الوكيل بطابور رسائل معلقة لكل نظير. عندما تصل إجابة مرتبطة، تُحذف المعاملة من الطابور. وعند بدء failover، تُرسل كل الرسائل المتبقية إلى وكيل بديل متاح.

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

لذلك يحتاج إيصال الإعادة إلى هوية النظير القديم والبديل، وسبب التحويل، وجيل watchdog، ولقطة الطابور، وهوية end-to-end، وبصمة المحتوى، وعلامة retransmission، وأوقات الإرسال. لا تكشف كلمة retry إن كانت البايتات نفسها قد نُسخت أو أعيد بناء رسالة مختلفة.

احتفظت RFC 6733 بهذه الحدود في Diameter Base Protocol. فهي تحيل الطلبات المعلقة إلى وكيل بديل مع علامة إعادة الإرسال، وتحذر من إمكان وصول عدة طلبات أو إجابات متطابقة نتيجة failover.

هوية hop لا تقوم بعمل هوية النهاية

يربط Hop-by-Hop Identifier إجابة بطلب معلق لدى الجار. أما End-to-End Identifier مع Origin-Host فيجمع الرسائل التي عبرت وكلاء مختلفين تحت معاملة منطقية واحدة.

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

عند اكتشاف التكرار، تبدأ مسألة التصرف. هل يعيد الخادم إجابة محفوظة، ينتظر مالك القرار، يرفض إعادة التقييم، أم يشغل السياسة من جديد؟ تطلب RFC 6733 عادة أن ينتج الطلب المكرر الإجابة نفسها، مع اختلاف تفاصيل hop. هذه قاعدة استقرار تمنع الهوية الواحدة من أن تصبح قراراً جديداً.

لكن القاعدة تحتاج ذاكرة قرار. إذا لم يُحفظ الجواب الأول، أو انتهت مدة cache، أو لم تصل الحالة إلى الخادم الثاني، فلا تصنع الهوية المشتركة القرار المفقود. اكتشاف التكرار، ومنعه، وتسوية التعارض، وتعويض أثر سابق عمليات مختلفة.

يمكن أن يكون Accept وReject منطقيين كل على حدة

تقدم RFC 3539 مثالاً لقيد الاستخدام المتزامن. يصل الطلب الأول بينما لا يعد المستخدم متصلاً، فيصدر الخادم Accept. تتغير الحالة. تصل النسخة المكررة إلى خادم آخر يرى جلسة قائمة ولا يسمح إلا بجلسة واحدة، فيصدر Reject.

لا يلزم أن يكون أحد الخادمين مخترقاً أو معطلاً. قد يطبق كل منهما القاعدة الصحيحة على snapshot مختلف. ينشأ التناقض من تأخر الحالة ومن عملية ليست idempotent.

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

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

لا تحذف الإجابة التي خسرت السباق

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

ويجب تعريف «الأول». قد يكون أول ما قرأه process، أو أول ما اجتاز التحقق، أو أول ما سُجل، أو أول ما أُرسل إلى NAS، أو أول ما أصبح نافذاً. هذه الترتيبات قد تختلف.

إيصال الاختيار يسرد الإجابات كلها، ونتيجة الربط والتحقق، والقاعدة التي اختارت، والجواب المختار، ومصير الآخر. بفضله يمكن فصل duplicate في النقل عن اختلاف الحالة وعن سباق التنفيذ.

الاحتفاظ بالخاسر ليس ضوضاء. إنه الدليل الوحيد على أن مسار الاستمرارية فتح سلطتين للقرار بدلاً من واحدة.

Accept ليس دخولاً بعد

Accept قرار من الخادم داخل حدوده. على العميل ربطه والتحقق منه، وعلى NAS تثبيت السمات أو profile وتغيير حالة الوصول. وبعد ذلك يلزم رصد data plane للتأكد من حصول المستخدم على الخدمة.

Reject محدود بالطريقة نفسها. إذا طُبق Accept سابقاً، فلا يثبت Reject المتأخر أن الوصول لم يحدث قط. ربما يطلق إغلاقاً، أو يُرمى بوصفه duplicate، أو يبقى تعارضاً يحتاج قراراً.

للمحاسبة سطح مستقل. تذكر RFC 3539 Accounting Session-Id وEvent-Timestamp وهوية NAS لإزالة السجلات المتكررة. يجب ربط قرار الحذف أو الدمج أو القبول بأثره على التدقيق والفوترة.

السلسلة الكاملة هي: نية الطلب، حياة النظير المباشر، نسخ الطابور، قرارات الخوادم، اختيار العميل، تنفيذ NAS، التصرف المحاسبي، ونتيجة المستخدم. لا يوقع مالك النقل عن مالك السياسة، ولا يوقع الخادم عن NAS.

لا تُعد تسمية حقول RADIUS بأسماء Diameter

لـRADIUS التقليدي إحداثياته: Identifier من بايت واحد، وRequest Authenticator، وسياق النقل، والسر المشترك. تحدد RFC 2865 وRFC 2866 وRFC 5080 حدود الربط وإعادة الإرسال فيه.

هذه الحقول ليست أسماء قديمة لـHop-by-Hop Identifier أو End-to-End Identifier أو Origin-Host. لا يعيد هذا المقال موضوع هوية RADIUS؛ بل يدرس النسخة العابرة للاتصالات في RFC 3539 وكيف تحولها حالة متغيرة إلى فرصة قرار ثانية.

المبدأ المشترك مجرد: احتفظ بهوية تكفي كي يبقى التكرار هو النية نفسها، وبحالة قرار تكفي كي لا تنتج النية أثرين.

ملف أدلة لاختبار التحويل

يبدأ الملف بهوية الطلب: origin، ومفتاح end-to-end، وبصمة ثابتة، ونطاق المستخدم أو الجلسة، والتطبيق، ووقت الإنشاء. ثم يسجل النظير: جيل الاتصال، وآخر جواب صالح، وwatchdog، والمؤقت وjitter، وتصنيف الفشل.

يسجل التحويل النظيرين، ولقطة الطابور، وعلامة الإعادة، والأوقات. ويسجل كل خادم state epoch والقيد والبحث عن duplicate والقرار وزمن commit. ويسجل العميل كل الإجابات وقاعدة الاختيار.

يقدم NAS إثبات التطبيق، وتربط المحاسبة هوية الجلسة والحدث وNAS بالتصرف، ثم يرصد النظام الوصول أو المنع الحقيقي.

عندها يمكن القول: «لم يرد هذا النظير المباشر على هذا watchdog؛ أُعيدت هذه الهويات المعلقة إلى هذا البديل؛ سُويت القرارات بهذه القاعدة؛ طبق NAS هذا الجواب؛ وكانت الجلسة والمحاسبة المرصودتان كذا». ما لا يوجد له إيصال يظل مجهولاً.

حدود الدليل

لا يحدد المقال مشغلاً أو مورداً أو AAA realm أو نشر RADIUS أو Diameter أو حساباً أو login أو NAS أو حادثة أو outage أو هجوماً أو رسماً مكرراً أو مستخدماً. ولا يعلن معدل تبنٍّ أو إعداداً حالياً أو latency مقاسة أو تكراراً فعلياً لردود متعارضة.

تُعامل RFC 3539 بوصفها Proposed Standard من يونيو 2003. RFC 3588 سياق تاريخي وقد استبدلتها RFC 6733. تحتفظ RFC 6733 بخوارزمية العطل وهوية التكرار لكنها لا تثبت امتثال نظام مسمى. تحد RFC 8174 لغة الإلزام، وتقدم RFC 6298 سياق المؤقت لا واقعة AAA.

مقالا Lu Heng عن أولوية الكود العامل والحد الأدنى للمواصفة الأولية عدسة تحريرية معلنة للفصل بين النص والتنفيذ والقرار المحلي والنتيجة. لا يثبتان قصد مؤلفي RFC أو سلوك نشر.

الخلاصة المحدودة: قد ينسخ failover طلب AAA قبل اختفاء الأصل. تجعل الهوية المشتركة النسخ قابلة للتعرف. وحدها معالجة idempotent، واختيار معلن، وتنفيذ مثبت، ونتيجة مرصودة تثبت أثراً واحداً.

المصادر