الخلاصة

  • أتاح NAT توفير عناوين IPv4 الفريدة عالميًا عند حدود الشبكة، لكن التطبيقات التي تعتمد على قيم العناوين احتاجت إلى أكثر من إعادة كتابة ترويسة IP.
  • تمحور التحذير التاريخي في RFC 2993 حول الجهة التي ستتحمل العمل المتبقي: بوابات التطبيقات، وتحديث الأطراف بالتنسيق، وإدارة الأسماء والدعم محليًا، لا مجرد صندوق على مسار الموجّه.

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

كان هذا التوتر ظاهرًا منذ مقترح عام 1994. قدّم RFC 1631 ترجمة عناوين الشبكة بوصفها استجابة تدريجية لضغط عناوين IPv4: تعيد الشبكات الطرفية استخدام عناوينها الداخلية، ويترجم جهاز عند الحد حركة المرور الخارجة إلى فضاء العناوين العامة. وأقرّ النص بالمقابل أيضًا: تتراجع دلالة عنوان IP من طرف إلى طرف، وتحل محلها حالة إضافية داخل الشبكة. وإذا كان للموقع أكثر من منفذ خروج، وجب أن تتفق المترجمات على جدول التحويل. كان ذلك جسرًا عمليًا، لا تصميمًا بلا كلفة.

في نوفمبر 2000، أعاد Tony Hain النظر في NAT بعد ست سنوات من اتساع الاهتمام والنشر في RFC 2993. لم يعد السؤال مقتصرًا على قدرة الموجّه على استبدال عنوان بآخر، بل صار: هل تستمر الخدمة حين يظهر العنوان في موضع لا يفحصه المترجم؟

تختلف الإجابة باختلاف التطبيق. قد يسهل نسبيًا التعامل مع اتصال بسيط بين طرفين يمر عبر NAT واحد. لكن بعض البروتوكولات تحمل عناوين IP في محتوى الرسالة، بينما يعتمد بعضها الآخر على اتساق الترويسة في حسابات التحقق أو المصادقة أو الأمن. ولا يستطيع مترجم يكتفي بفحص الترويسة إصلاح كل هذه الافتراضات. قد تساعد بوابات طبقة التطبيق (ALG) والوكلاء، لكن على كل منها أن يفهم البروتوكول الذي يعالجه. وقد أشار RFC 2775 إلى أمر مشابه في مطلع العام نفسه: يلزم تحديث البوابة أو الوكيل عند ظهور تطبيق جديد يعتمد على العناوين.

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

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

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

جعل الأمن الفرق بين الترجمة والسياسة أوضح. حذّر RFC من أن NAT، ولا سيما ترجمة المنافذ، قد يوحي بوجود حاجز أمني من دون قصد التحكم في الوصول الذي يميز جدار الحماية. وناقش أيضًا مشكلات توافق تخص IPsec وسلوك DNS ومصادقة SNMPv3. تعتمد هذه الآليات على البروتوكول والإعداد؛ ولا تثبت أن كل NAT يعطل كل بروتوكول أمني. يغيّر المترجم أدلة تعتمد على العنوان، لكنه لا يقرر بمفرده أي حركة مرور ينبغي السماح بها.

جعلت الوثائق اللاحقة العمل أكثر وضوحًا، لكنها لا تثبت اختفاء المشكلة. حلّ RFC 3022 محل RFC 1631 عام 2001 ووصف NAT التقليدي، ثم قدم RFC 3235 عام 2002 إرشادات لمصممي التطبيقات المتوافقة مع NAT. لا تثبت هذه النصوص أن RFC 2993 سبّب نشرًا معينًا أو أن كل البرامج اتبعت الإرشادات؛ لكنها تبين أن تقنية الحدود أفضت إلى أدبيات تصميم للتطبيقات.

ليست القيمة التاريخية لـ RFC 2993 حكمًا بأن NAT يفشل دائمًا. بل إنه يفصل بين توفير العناوين عند الحد وبين أعمال التوافق اللازمة فوقه. أمكن وضع المترجم عند بوابة واحدة، لكن الإصلاح قد يتطلب تحديث التطبيق لدى أطراف كثيرة، والحفاظ على حالة متسقة عبر مسارات متعددة، وإدارة الأسماء محليًا. لم تختفِ الأعمال؛ بل تغيرت الجهة التي ينبغي أن تلاحظها وتنسقها.

المصادر