الخلاصة

  • أتاحت RFC 4014 لمسؤول الوصول إلى الشبكة حفظ بعض السمات الواردة في رسالة Access-Accept ناجحة من RADIUS، ثم تضمينها لاحقاً في رسالة DHCP يمررها المرحّل.
  • يستخدم خادم DHCP هذه السمات لاختيار معلمات الإعداد. ويظل التفويض عبر RADIUS، ونقل السياق عبر المرحّل، وتخصيص عنوان DHCP وظائف منفصلة.

الموافقة على الدخول لا تمنح عنواناً

يتصل جهاز بنقطة وصول لاسلكية أو بمنفذ في شبكة مؤسسة. تنجح مصادقة 802.1X، فيسمح المفتاح أو الجهاز اللاسلكي للجلسة بالمرور. لكن الاتصال العادي عبر IP يتطلب خطوة أخرى: على الجهاز الحصول على إعداداته عبر DHCP. في تلك اللحظة تكون الشبكة قد أجابت عن سؤال «هل يُسمح له بالدخول؟» ولم تجب بعد عن سؤال «ما الإعداد الذي سيحصل عليه؟».

يعالج RADIUS وDHCP سؤالين مختلفين. يستطيع RADIUS المصادقة وإرجاع سمات مرتبطة بالتفويض. أما DHCP فيختار معلمات الشبكة التي يقدمها للعميل وفق سياساته. وتوضح RFC 3580 أن IEEE 802.1X لا يوفر بذاته آلية لتخصيص عناوين IP؛ ولا تكون سمة مثل Framed-Pool نافعة إلا عندما يستطيع جهاز المصادقة المشاركة في عملية التخصيص.

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

في فبراير 2005، وضع Ralph Droms وJohn Schnizlein هذا النقل في مواصفة Standards Track هي RFC 4014. بعد Access-Accept ناجحة، يحتفظ NAS بالسمات محلياً. وعندما يمرر لاحقاً رسالة DHCP من العميل، يمكنه إرفاق مجموعة منتقاة منها. لا تحول المواصفة قرار RADIUS إلى عقد إيجار DHCP؛ إنها تحدد طريقاً بين تبادلين.

غلاف معلومات المرحّل كان موجوداً من قبل

استفادت RFC 4014 من خيار Relay Agent Information الذي عرفته RFC 3046، ويُعرف أيضاً باسم Option 82. فهذا الخيار غلاف لمعلومات يعرفها المرحّل عن موقع الطلب، مثل الدائرة التي وصل عبرها أو الجهاز البعيد المرتبط بها. يمكن لخادم DHCP استخدام هذه المعلومات لاختيار عنوان أو معلمات أخرى.

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

أضافت RFC 4014 داخل هذا الغلاف الخيار الفرعي رقم 7، «RADIUS Attributes». ويمكن للمرحّل أن يضع فيه الترميز بالبايت للسمات الواردة في Access-Accept. يستخرج خادم DHCP محتواه ويستخدمه لاختيار الإعداد. ينقل المرحّل السياق؛ لكنه لا يتخذ قرار التخصيص النهائي.

لم تحصر المواصفة الاستخدام في 802.1X، إذ يمكن للمرحّل نقل سمات حصل عليها لأسباب أخرى ما دامت تتبع دلالات RADIUS. لكن ضمان قابلية التشغيل البيني القوية ظل محلياً: يجب أن تكون خدمتا RADIUS وDHCP ضمن نطاق إداري محلي واحد. لم تعد المواصفة بتفسير موحد بين نطاقات مستقلة حول العالم.

القائمة المحدودة تؤدي وظيفة مهمة

لا يجوز أن تضم الرسالة أكثر من خيار فرعي واحد لسمات RADIUS. وإذا كانت سماتا User-Name وFramed-Pool متاحتين، فيجب تضمينهما؛ أما غيرهما فيجوز إضافته. ولتجنب اعتماد تخصيص العناوين على حالة أخرى يحتفظ بها خادم RADIUS وحده، أوصت المواصفة بحصر السمات في ست: User-Name وService-Type وVendor-Specific وSession-Timeout وFramed-Pool وFramed-IPv6-Pool.

يستخدم خادم DHCP ما استلمه لاختيار معلمات الإعداد، ومن المفترض أن يتجاهل السمات خارج القائمة. قد يؤثر اسم مجمع عناوين في اختيار سياسة، لكنه لا يجبر الخادم على منح عنوان من مجمع لا يديره. يوفر التفويض سياقاً؛ وتظل إدارة العناوين والقرار النهائي لدى خدمة DHCP.

تفرض المساحة المحدودة للرسالة قيداً آخر. تقول RFC 4014 إن المرحّل يقتطع السمات كي تتسع لها الخانة، لكنها لا تضع خوارزمية عامة لترتيب ما يبقى. لذلك لا يكفي أن نعرف أن سمة ما ظهرت في Access-Accept كي نجزم بوصولها كاملة إلى خادم DHCP. يجب فحص الرسالة التي عُبرت فعلاً ومعرفة سلوك التنفيذ عند الحد الأقصى.

ويتحمل NAS مسؤولية الاحتفاظ بالحالة المناسبة: عليه ربط السمات المحفوظة بالجلسة التي ترسل طلب DHCP لاحقاً. لا تحدد RFC 4014 بنية جدول الجلسات ولا كيفية تحديثه بعد إعادة المصادقة أو تغيير السياسة. هذه أسئلة تشغيلية يتركها الحد الفاصل بين المواصفة والتنفيذ المحلي.

الثقة تسلك المسار نفسه

ما دام خادم DHCP يستخدم قيماً يرسلها المرحّل لاختيار الإعداد، فإن الثقة بين المرحّل والخادم جزء من مسار التحكم. تعتمد RFC 4014 على علاقة الثقة التي تصفها RFC 3046. وتوصي بحماية أعمق، مثل مصادقة خيارات المرحّل أو استخدام IPsec، إلى جانب قواعد الشبكة الطرفية التي لا تقبل Option 82 إلا من المرحلات الموثوقة.

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

لهذا لا توجد إجابة من جهة واحدة عن سؤال «من اختار العنوان؟». يقرر RADIUS أن الجلسة مخولة ويرسل السياق؛ ويقرر NAS ما الذي سينقله؛ ويختار خادم DHCP الإعداد من الموارد التي يديرها. تحدد المواصفة مسار المعلومات، لكنها لا تثبت حداثة الحالة ولا موثوقية المرحّل ولا صحة السياسة المحلية. وحده سلوك الأنظمة العاملة يبين النتيجة الفعلية.

توسعة 2023 أبقت مسارين مختلفين

عادت RFC 9445 إلى هذه الحدود عام 2023 بعدما احتاجت خدمات جديدة إلى معلمات DHCP تتجاوز القائمة المجمدة في RFC 4014. فحدّثت المواصفة عبر نقل السمات المسموح بها إلى سجل لدى IANA، مع إمكان التوسع فيه وفق مراجعة الخبراء. هذا توسيع لمسار الخيار الفرعي 7 نفسه.

كما عرّفت RFC 9445 سمتين مختلفتين تحملان خيارات DHCP داخل RADIUS: DHCPv6-Options بالمعرّف 245.3 وDHCPv4-Options بالمعرّف 245.4. ويعرض مثال DNS المشفر أحد الاستخدامات الممكنة، لكنه لا يقيس مدى انتشاره. هاتان السمتان ليستا الخيار الفرعي 7. يسجل جدول IANA ما هو مسموح به، لا ما نشره المشغلون في شبكاتهم.

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

ومن منظور تحليلي لاحق، تطرح Note 64 للكاتب Lu Heng فكرة الحد الأدنى للمواصفة المشتركة وترك القرارات التالية للنطاق الإداري الذي يشغّل الأنظمة. وتذكّر Note 65 بأن نشر وثيقة لا يثبت أن الشيفرة تعمل بها. هاتان ملاحظتان لاحقتان وليستا سبباً أو مصدراً تاريخياً لـ RFC 4014. الاختبار العملي هو ما إذا كانت أنظمة NAS والمرحّل وخادم DHCP العاملة تنقل السياق الصحيح وتستخدمه كما هو متوقع.

المصادر