الخلاصة

  • جعلت RFC 4008 الواجهات وفئات الخدمة ومعلمات الإعداد محوراً لإدارة NAT؛ وتشرح RFC 7658 لماذا لم يلائم هذا الافتراض كثيراً من التطبيقات.
  • قلّصت NATV2-MIB مساحة الإعداد المشتركة، مع توسيع ما يمكن ملاحظته عن المثيلات المنطقية ونطاقات العناوين والمشتركين والمجمّعات والحالة.

يبدأ الإعداد بواجهة

في تسلسل الإعداد الذي تعرضه RFC 4008 عبر SNMP، ينشئ مدير الشبكة أولاً صفاً في natInterfaceTable. عليه أن يعرف ifIndex موجوداً، ثم يحدد إن كانت الواجهة ضمن نطاق خاص أو عام. بعد ذلك يضيف خرائط عناوين مرتبطة بالمؤشر نفسه، ويضبط مهلات افتراضية. وهكذا لا يكون أول عنصر في النموذج قاعدة التحويل، بل الحافة المادية التي ستُنظَّم القاعدة حولها.

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

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

مراجعة معيارية صريحة

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

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

وأظهرت الفئات وقائمة البروتوكولات حدوداً مشابهة. استخدمت RFC 4008 الفئات basicNat وnapt وbidirectionalNat وtwiceNat. ورأت RFC 7658 أنها غير محددة جيداً، إذ استخدمت التطبيقات فئات أخرى أو لم تستخدم فئات من الأصل. وهذه فئات خدمات MIB القديمة، لا تصنيف NAT المخروطي في RFC 3489. أما النموذج اللاحق فاستند إلى مصطلحات سلوك NAT في RFC 4787. كما استبدل قائمة other وICMP وUDP وTCP، ذات الأرقام الخاصة غير المرتبطة بأرقام البروتوكول القياسية، بأرقام سجل IANA؛ وبذلك أصبح تمثيل بروتوكولات مثل DCCP وSCTP أكثر اتساقاً.

تغيير التجريد لا إضافة أعمدة

في عام 2015 قُسم الانتقال إلى وثيقتين. أبقت RFC 7658 تعريفات كائنات RFC 4008، لكنها غيّرت حالتها إلى deprecated. ثم عرّفت RFC 7659 وحدة NATV2-MIB. لم تُعَد تسمية الكائنات القديمة أو تفسيرها سراً وكأن معناها لم يتغير. RFC 7658 RFC 7659

صُممت NATV2-MIB أساساً للمراقبة. واقتصرت معلومات التهيئة للقراءة على ما يلزم لفهم الحالة والإحصاءات. وأُزيلت التهيئة القابلة للكتابة إلا في ما يتعلق بالتحكم في الإشعارات وحصص موارد NAT. لم يختف التحكم كله؛ فما زال المشغل يستطيع ضبط حدود وقائية. لكن MIB لم تعد تعد بواجهة واحدة لتهيئة محركات تحويل تختلف بنيتها.

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

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

وتوضح RFC 6888 سياق الموارد المشتركة: يتنافس مشتركو CGN على المنافذ وحالة NAT، ويمكن للحدود المفروضة لكل مشترك أن تقلل الاستهلاك المفرط لمورد مشترك. وتتيح NATV2-MIB تمثيل بعض هذه الحدود وملاحظة جانب من حالتها. لكن النصوص لا تحدد المشغلين الذين استخدموا تلك الكائنات، ولا العتبات التي اختاروها، ولا نتائج السياسة في التشغيل الفعلي. RFC 6888، القسمان 4 و5

ما الذي تثبته هذه القصة

تاريخ NAT-MIB هو تصحيح للتجريد. حاولت RFC 4008 جعل NAT قابلاً للتهيئة عبر بنية جداول موحدة. ثم شرحت RFC 7658 لماذا لم تناسب الواجهات ومعلمات الإعداد وفئات الخدمة وقائمة البروتوكولات المغلقة كثيراً من التطبيقات. وقلصت RFC 7659 مساحة الكتابة المشتركة، في الوقت الذي وسّعت فيه وصف المثيلات المنطقية والموارد المشتركة.

والاستنتاج الذي تدعمه النصوص محدود: تغيّر نموذج الإدارة لكي يصف نطاقاً أوسع من التطبيقات. لا يثبت ذلك أن كل مصنع اعتمد NATV2-MIB، أو أنها أصبحت معياراً شائعاً، أو أنها حسّنت أداء التحويل. وتقول RFC 7659 إن NAT-MIB الأولى لم تُنفذ على نطاق واسع، من دون نسبة أو قياس مماثل لاعتماد الخلف.

أما حدّ وظائف الجدار الناري فواضح. تنص RFC 4008 وRFC 7658 على أن وحدتي MIB لا تعالجان وظائف الجدار الناري، ولا يجوز استخدامهما لتهيئتها أو مراقبتها. صف الترجمة ليس قاعدة تصفية.

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

الدرس التاريخي هنا عملي ومحدد: قد يصبح معيار الإدارة أوسع من اللازم عندما يحول عناصر تحكم خاصة بالتطبيق إلى واجهة مشتركة. لم ترد RFC 7658 بإضافة حقول أخرى إلى جدول الواجهات، بل أعادت النظر في الوحدة التي ينبغي نمذجتها. جعلت MIB اللاحقة قدراً أقل من التهيئة وعداً عاماً، وجعلت سياقاً منطقياً أكبر قابلاً للملاحظة. لم يعد السؤال فقط «أي واجهة تملك هذا التعيين؟»، بل «أي مثيل ونطاق ومشترك ومجمّع وحالة تصفها هذه الملاحظة؟»

المصادر