الخلاصة

  • تحدد RFC 5417 خياري DHCPv4 وDHCPv6 منفصلين يحملان قوائم مرتبة لعناوين متحكمات CAPWAP؛ ويأتي الترتيب من سياسة خادم DHCP المضبوطة.
  • يمكن لنقطة الإنهاء اللاسلكية استخدام القائمة، وينبغي أن تجرب العناوين بالترتيب الوارد، لكن ذلك لا يثبت إمكانية الوصول أو هوية الطرف. يتولى DTLS مصادقة الطرفين عند إنشاء الجلسة.

في كثير من الشبكات تصل إجابة DHCP قبل مصادقة الوصول إلى الشبكة. لذلك تقع قائمة المتحكمات عند حد حساس في عملية الإقلاع: يمكنها توجيه نقطة الإنهاء اللاسلكية (WTP) إلى مرشح أول، لكنها لا تثبت هوية ذلك المرشح. وتشرح RFC 5417 كيف تُرتب هذه العناوين قبل أن تبدأ مراحل CAPWAP اللاحقة.

الخياران منفصلان بحسب عائلة العناوين. يحمل خيار DHCPv4 رقم 138 عناوين IPv4 بطول 32 بت، ولذلك يجب أن يكون طول بياناته من مضاعفات أربعة أوكتات. ويحمل خيار DHCPv6 رقم 52 عناوين IPv6 بطول 128 بت، على أن يكون الطول من مضاعفات ستة عشر أوكتات. يجب على عميل DHCP الذي يعمل نيابة عن WTP أن يطلب الخيار المعني في قائمة المعلمات المطلوبة. ولا يعيد الخادم الخيار إلا إذا كانت سياسته مضبوطة على نحو مناسب وكانت لديه قائمة بعناوين المتحكمات.

هذا الشرط يجعل الترتيب جزءاً من إعداد الخادم، لا قياساً تلقائياً للتوافر. تنص RFC 5417 على ترتيب العناوين بحسب الأفضلية، وتسمح لـ WTP باستخدام القائمة للعثور على متحكم. كما تقول إن على WTP أن يجرب السجلات بالترتيب الوارد. لهذا التسلسل أثر فعلي في مسار البحث، لكنه لا يضمن الخدمة: لا يجعل العنوان قابلاً للوصول، ولا يقيس حمل المتحكم، ولا يضمن قبول المتحكم الأول لـ WTP.

ولا ينبغي دمج قائمتي IPv4 وIPv6 في ترتيب واحد لم تحدده الوثيقة. تنظم RFC 5417 الأفضلية داخل كل خيار، لكنها لا تضع ترتيباً مشتركاً يعبر عائلتي العناوين. إذا كان المقصود أن يعبر العنوان الأول في كل قائمة عن التفضيل نفسه، فعلى الإعداد المحلي أن يوضح هذه العلاقة.

ورود عنوان في القائمة لا يجعل المتحكم موثوقاً. يمنح DHCP نقطة الإنهاء أول دليل على وجهتها؛ أما اكتشاف CAPWAP وإنشاء الجلسة فلهما عمل مختلف. تشرح RFC 5415 رسائل الاكتشاف ومسار الجلسة. وتحذر اعتبارات الأمن في RFC 5417 من أن مهاجماً يعدل رد DHCP أو يدرج رداً خاصاً قد يوجه WTP إلى متحكم CAPWAP خبيث يمكنه اعتراض طلبات الاتصال أو حجب الخدمة. ويجب أن يستخدم CAPWAP بروتوكول DTLS لمصادقة الطرفين عند إنشاء الجلسة.

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

ما زالت IANA تسجل خيار DHCPv4 رقم 138 باسم OPTION_CAPWAP_AC_V4 وخيار DHCPv6 رقم 52 باسم OPTION_CAPWAP_AC_V6، مع الإشارة إلى RFC 5417. يثبت ذلك أن القيم ما زالت مسجلة؛ لكنه لا يثبت مدى انتشار دعمها في المنتجات الحالية أو كيف تتصرف نقطة WTP بعينها عند فشل محاولة.

بالنسبة إلى المشغل، المهم هو السلسلة كاملة: هل طلب WTP الخيار؟ وما القائمة التي أعادها الخادم لكل نطاق وعائلة عناوين؟ وهل لكل عنوان مسار وخدمة تستمع؟ وماذا أعاد اكتشاف CAPWAP؟ وهل صادق DTLS الطرف المقصود؟ تُظهر حزمة تتضمن الخيار 138 أو 52 ما نقله DHCP، لكنها لا تثبت أن WTP وصل إلى المتحكم المتوقع أو أنشأ جلسة تحكم قابلة للاستخدام.

إسهام RFC 5417 محدود لكنه مهم. فهو يسمح لسياسة DHCP بالتأثير في ترتيب بحث جهاز لاسلكي عن مستوى إدارته، من دون أن يحول التفضيل المضبوط إلى انتخاب حي أو حكم أمني. وفي ترحيل المتحكمات، يصبح القرار أوضح عند فصل المراحل: القائمة تعبر عن النية، والاكتشاف يختبر المرشحين، وDTLS يصادق الطرف الذي يتابع.

المصادر