الخلاصة

  • استخدمت RFC 5381 ملفات WSDL وXML Schema وأداة Apache Axis لتوليد واجهات عميل وهياكل خادم لـNETCONF فوق SOAP، لكن الوظائف الفعلية وسياسات السلطة بقيت خارج التوليد.
  • ربط التنفيذ معرّف جلسة NETCONF بملف cookie في HTTP، فنجح بين طرفين متفقين على القاعدة الخاصة، بينما يصرح النص بأنه لا يتوافق تشغيلياً مع تنفيذ ملتزم بـRFC 4743.

القفل الذي لا يحدد صاحب الباب

تطلب RFC 5381 استخدام TLS للمصادقة والتشفير عند تشغيل NETCONF فوق SOAP وHTTPS. هذا مطلب مهم: يمكن للمشغل أن يعرف هوية نظيره وفق ملف الثقة، وأن يحمي الرسالة من القراءة أو التغيير أثناء النقل.

لكن TLS لا يقرر من يملك جلسة NETCONF. لا يقرر أن الهوية الموثقة مسموح لها بتنفيذ edit-config. ولا يشهد بأن التغيير وصل إلى datastore الصحيح، أو اجتاز التحقق، أو نُفذ في الجهاز، أو غيّر سلوك الشبكة كما أراد صاحبه.

الأمن هنا يجيب عن سؤال محدد: ما علاقة الحماية حول القناة؟ الخطأ الإداري يبدأ حين تُستخدم الإجابة نفسها لسؤال أوسع: هل كان الفعل مخولاً وناجحاً؟

حين حملت الجلسة ثلاث علامات

تحتاج NETCONF إلى حالة جلسة مستمرة. في RFC 4743 ارتبطت تلك الحالة باتصال النقل الدائم عند استخدام HTTP. واجه مؤلفو RFC 5381 واقعاً مختلفاً: كثير من خوادم HTTP تعالج كل طلب بمعزل عن الطلب السابق. لتبسيط مزود خدمة NETCONF، وضع التنفيذ معرّف الجلسة في cookie داخل رأس HTTP، إضافة إلى عنصر الجلسة في رسالة NETCONF.

بعد hello يخصص الجهاز المعرّف ويرسله في الموضعين. يحتفظ به نظام إدارة الشبكة ويعيده في الطلبات اللاحقة. وعند close-session تُمحى القيمة.

يمكن لهذا التنظيم أن يعمل بإحكام داخل الزوج نفسه. لكنه ينشئ ثلاثة شهود محتملين: اتصال TCP، وcookie HTTP، وعنصر NETCONF. ماذا يحدث إذا تغيّر الاتصال وبقي cookie؟ ماذا لو نقل وسيط الطلب إلى عملية أخرى؟ ماذا لو اختلفت القيمة في XML عن الرأس؟

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

التوليد لا يفوّض

أنتج Apache Axis فئات Java من WSDL. ظهر للعميل stub يمكن استدعاؤه كواجهة محلية. وظهر للخادم skeleton يحتاج إلى إضافة وظائف مزود NETCONF. قلّل ذلك كتابة XML وSOAP يدوياً، لكنه لم يحدد صاحب الصلاحية.

حتى وصف الخدمة كان مركباً. ملف الربط الأساسي لم يتضمن عنصر service، فاحتاج إلى ملف آخر يحدد endpoint. ونماذج وظائف الجهاز احتاجت إلى XML Schema خاص بها. وكل اختيار يدخله المطور في الوصف أو في الكود اليدوي يمكن أن يغيّر سطح الإدارة.

نجاح المولد يثبت علاقة بين مدخل ومخرج. نجاح compiler يثبت سلامة لغوية. نجاح deployment يثبت أن الحاوية حمّلت الشيفرة. لا واحد منها يثبت أن principal الموثق مخول بتعديل مسار أو مرشح أو واجهة.

لذلك يجب أن يحتفظ كل RPC بقرار تفويض مستقل: من طلب، وما القدرة المعلنة، وما الهدف، وما السياسة التي سمحت، ومتى انتهت صلاحيتها.

الوصول إلى endpoint ليس وصولاً إلى النتيجة

توضح البنية على الجهاز مساراً متدرجاً. يستقبل HTTP daemon الرسالة. تزيل وحدة SOAP الغلاف. يقرأ مزود NETCONF المحتوى. ثم يحاول تغيير الجهاز. في بيئة محدودة الذاكرة قد تُكتب هذه الأجزاء بلغة C، وقد يعالج parser الأجزاء الإلزامية فقط من SOAP.

يمكن أن يكون endpoint متاحاً قبل اكتمال الوظائف. ويمكن أن يكون SOAP صحيحاً بينما يرفض NETCONF العملية. ويمكن أن يقبل NETCONF الطلب ثم تمنعه سياسة الوصول. ويمكن أن يتغير datastore من دون أن تتحقق النتيجة التشغيلية المتوقعة.

هذه ليست سلسلة نجاح واحدة، بل سلسلة سلطات. HTTP يملك الاستقبال. TLS يملك علاقة القناة. SOAP يملك التغليف. NETCONF يملك دلالة العملية والجلسة. نظام التفويض يملك الإذن. الجهاز يملك التحقيق. والمراقبة المستقلة تملك الشهادة على النتيجة.

إذا حُولت السلسلة كلها إلى مؤشر أخضر واحد، ينتقل وزن الدليل إلى أول طبقة تستطيع الرد.

متطلب SSH يرسم حدود الامتثال

أشارت ملاحظة IESG إلى أن تطبيق NETCONF الذي يدعم SOAP وحده، من دون دعم SSH على الأقل، لم يكن ممتثلاً لمعايير NETCONF وقتها. هذه نقطة مهمة للحكم الأمني. قد يكون SOAP/HTTPS آمناً ضمن ملفه، لكنه لا يملأ تلقائياً السطح الإلزامي الكامل.

الامتثال ليس جمعاً عشوائياً لضوابط جيدة. هو عقد يحدد أي قدرات يجب أن توجد وكيف تتفاعل. شهادة TLS لا تعوّض transport مطلوباً، كما أن transport مطلوباً لا يعوّض قرار authorization لكل عملية.

ما يبقى بعد انتهاء العمر العام

حلت RFC 6241 محل قاعدة NETCONF القديمة، وحددت RFC 6242 ربط SSH المحدث. ثم جعلت RFC 9900 ربطَي SOAP وBEEP تاريخيين وحررت أرقام المنافذ.

لكن القرار العام لا يمحو صور firmware، أو WSDL منسوخاً، أو cookie قديمة، أو سياسة جدار ناري في شبكة خاصة. يملك مقال BTW عن RFC 9900 موضوع الفصل بين السجل العام والتقاعد المحلي. أما هذا المقال فيملك سؤال السلطة: إذا بقي النظام، فبأي عقد يربط الهوية بالجلسة وبالفعل؟

يؤكد منهج Heng Lu أولوية الكود الجاري. هنا لا تكفي رؤية الكود؛ يجب معرفة الوصف الذي ولده، والقاعدة الخاصة التي ربطت حالته، والسياسة التي منحته السلطة، والملاحظة التي أثبتت أثره.

المصادر