الخلاصة

  • قدمت RFC 1215 ماكرو TRAP-TYPE لربط سلطة التسجيل والمتغيرات المرتبة والمعنى النصي والعدد الصحيح بحقول Trap-PDU في SNMPv1. يحدث التوسيع وقت التنفيذ البرمجي، لا عند وقوع الحادث.
  • عبّر الفخ عما تعرّف عليه تطبيق أو كيان البروتوكول المرسل. لم يثبت وحده عطلًا ماديًا أو سببًا جذريًا أو أثرًا على المستخدم أو هوية موثقة.
  • استخدم SNMPv1 خدمة datagram غير موثوقة، واختارت كل بيئة وجهاتها بطريقتها. بقي التعريف والتعرّف والإنشاء والإرسال والاستلام والتأكيد والإجراء حقائق منفصلة.

كان القالب يسبق الإشارة

تضع RFC 1215 الحد في جملة قصيرة: يتم توسيع TRAP-TYPE من الناحية المفاهيمية أثناء بناء التطبيق، لا أثناء التشغيل.

يستطيع المطور تعريف myLinkDown واختيار متغيراته وتجهيز شاشة المدير قبل أن يتعطل أي رابط. يصبح لدى النظام قاموس ونسق متفق عليهما، لا قراءة من مستشعر.

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

يؤرخ سجل RFC Editor الوثيقة في مارس 1991 ويصنفها Informational، ويحفظ IETF Datatracker الهوية نفسها. تصف الوثيقة استعمال الفخاخ بأنه مثير للجدل، وتنصح بشدة بعدم استعمالها، وتقصر غرض الماكرو على تعريف الفخاخ الموجودة بإيجاز لا تشجيع إنشاء فخاخ جديدة.

لا تعني هذه الحيطة أن الفخاخ لم تُستخدم. إنها تحدد سلطة النص: اتفاق وصفي، لا معيار إنترنت ولا تأييد عام.

دل ENTERPRISE على سجل لا على مرسل موثق

كان ENTERPRISE إلزاميًا. سمّى مؤسسة الإدارة التي يقع تعريف الفخ تحت سلطة تسجيلها، ووضع قيمتها في حقل enterprise داخل Trap-PDU.

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

قد تختلف المؤسسة التي سجلت النوع عن مالك المنتج الحالي، وعن المدمج، وعن المسؤول المحلي، وعن العملية المرسلة. لا يجمع OID هذه الجهات في هوية واحدة.

يقول قسم الأمن في RFC 1215 إن الوثيقة لا تناقش مسائل الأمن. لذلك لا يمكن استخراج مصادقة مصدر أو سلامة أو سرية أو حماية من الإعادة من صيغة التعريف.

كان ترتيب المتغيرات عقدًا أدنى

حدد VARIABLES التسلسل المرتب لكائنات MIB الموجودة في كل مثيل من النوع. واستطاع الوكيل إلحاق متغيرات إضافية بعدها.

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

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

يعطي DESCRIPTION المعنى النصي، ويمكن أن يشير REFERENCE إلى فخ أو حدث أو إنذار في وحدة أخرى. الأول نص مواصفة، والثاني علاقة بين تعريفات؛ ولا يمثل أي منهما مراقبًا مستقلًا للعالم.

تذهب القيمة الصحيحة في الفخ المؤسسي إلى specific-trap، بينما يصبح generic-trap مساويًا enterpriseSpecific(6). وفي اتفاق snmp تذهب القيمة إلى generic-trap ويصبح specific-trap صفرًا. إنها قيمة في نطاق أسماء، وليست درجة شدة أو ثقة أو ترتيبًا زمنيًا أو عددًا للحوادث.

وصف linkDown حكم الجهة المرسلة

يقول مثال myLinkDown إن تطبيق SNMP المرسل يتعرف على فشل في رابط اتصالات ممثل داخل تهيئة الوكيل. الفاعل في الجملة هو التطبيق المرسل.

ربما اعتمد التطبيق على حالة driver أو عداد أو عتبة أو انتقال محلي. لا يفحص الفخ الوسط المادي من مصدر مستقل، ولا يثبت السبب الجذري أو مسؤولية ناقل أو أثرًا على المستخدمين.

تستخدم RFC 1157 الحد نفسه في linkDown العام: يتعرف كيان البروتوكول المرسل على الفشل، ويحدد أول variable-binding مثيل ifIndex المتأثر. يحدد المؤشر سجلًا، لا شجرة العطل كاملة.

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

احتاج الإنشاء إلى طلب من التطبيق

تنص RFC 1157 على أن كيان البروتوكول لا ينشئ Trap-PDU إلا بطلب من تطبيق SNMP، وأن اختيار الوجهات خاص بالتنفيذ.

تقف إذن سياسة محلية بين التعريف والحزمة. قد لا يتعرف التطبيق على الحالة، أو لا يطلب الإنشاء، أو يمنع التنفيذ الإرسال، أو يختار وجهة قديمة، أو يستلم المدير PDU دون أن يعرف معناه المؤسسي.

يبين مثال authenticationFailure غموض الصمت. يجب أن يستطيع التنفيذ إنشاء هذا الفخ، ويجب أن يستطيع أيضًا منع إرساله بآلية خاصة به. عدم وصول فخ لا يثبت عدم وجود إخفاقات مصادقة؛ فقد يكون السبب عدم التعرف أو المنع أو سوء العنوان أو الفقد أو غياب المعالجة.

كان UDP 162 عنوان خدمة لا إيصالًا

اكتفى SNMPv1 بخدمة datagram غير موثوقة، ومثّل كل رسالة في datagram مستقل. وحددت RFC 1157 منفذ UDP 162 لاستقبال رسائل الفخ من أجل المعالجة اللاحقة.

لا يثبت المنفذ وجود مستمع أو سماح الجدار الناري أو مساحة buffer أو نجاح التحليل أو الحفظ أو انتباه إنسان. سجل الإرسال يثبت محاولة، لا استلامًا.

عند الاستلام الفعلي، يقدم كيان البروتوكول محتويات Trap-PDU إلى تطبيق SNMP. هذه مرحلة استقبال محددة، لكنها لا تساوي الربط بين الأحداث أو فتح تذكرة أو قرارًا أو تغييرًا أو استعادة خدمة.

وضحت المواصفات اللاحقة الحد من دون أن تعيد كتابة سجل 1991. تضع RFC 2578 RFC 1215 ضمن SMIv1، وتستخدم NOTIFICATION-TYPE لتعريف صياغة وإشارات إشعار SMIv2. يبقى تعريف النوع مختلفًا عن حدوث المثيل.

وتقول RFC 3416 إن SNMPv2-Trap لا يرتبط بتأكيد تسليم. أما InformRequest فهو إشعار مؤكد، لكنه لا يضمن التسليم أيضًا. عند استلامه، يقدم المستقبل المحتوى إلى التطبيق ويرسل Response-PDU.

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

جاءت قيمة الفخ من سلسلة عهدته

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

أعطت RFC 1215 هؤلاء لغة مشتركة، لا سلطة موحدة. يصبح الفخ أقوى حين يقارن بالاستطلاع والعدادات وحالة التوجيه واختبارات الخدمة. أما وحده فهو ادعاء محدود صادر من جهة الإرسال.

المصادر