الخلاصة

  • تنص REQ-7 في RFC 5382 على ألا يستخدم مترجم العناوين التحميل الزائد للمنافذ مع TCP، أي ألا يمنح طرفين داخليين مختلفين تعيين العنوان والمنفذ الخارجي نفسه في وقت واحد.
  • إذا اعتمد المترجم على عنوان الطرف البعيد ومنفذه للتمييز بين المطالبين، فإن اتصالهما بالوجهة نفسها يمحو الفارق. ولا تعود الرباعية العامة دليلاً على صاحب واحد أو مسار عودة واحد.

حين يحتاج البلاغ إلى حقل لم يسجله أحد

تستخدم سجلات الإساءة عادة العنوان العام والمنفذ والبروتوكول والوقت. يستطيع المشغل مطابقة هذه القيم مع سجل الترجمة لمعرفة العنوان والمنفذ الداخليين. هذه المطابقة ليست هوية دائمة؛ إنها مطالبة مؤقتة مقيدة بزمن وجود التعيين ودقة الساعات وجودة السجل.

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

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

تشرح الفقرة 7.1 من RFC 5382 أن طرفين داخليين يشتركان في تعيين واحد لا يستطيعان إنشاء اتصالين متزامنين إلى طرف خارجي مشترك. ولهذا تقول REQ-7 بوضوح إن مترجم TCP يجب ألا يستخدم هذا السلوك.

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

التعيين المستقل لا يعني تعدد المطالبين

تطلب RFC 5382 أيضاً تعييناً مستقلاً عن الطرف البعيد في TCP. يستطيع زوج داخلي واحد الاحتفاظ بالتعيين نفسه عندما يتحدث مع وجهات متعددة. هذا يثبت استمرارية مطالبة واحدة ولا يخلق مطالبين جديدين.

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

الترشيح سطح مستقل أيضاً. قد يسمح NAT بالعودة من أي مصدر، أو من عناوين سبق الاتصال بها، أو من عنوان ومنفذ محددين. هذه سياسة إذن. لا تستطيع أن تحدد مستلماً داخلياً واحداً إذا كان التعيين نفسه قد مُنح لاثنين. وقد تناول تحليل BTW سابق الفرق بين تعيين NAT64 وسياسة الترشيح. السؤال هنا يسبق الإذن: لمن ينتمي المسار الذي سيسمح به المرشح؟

يجب أن تفصل السجلات بين صاحب التعيين، وسياسة الترشيح، ونجاح مصافحة TCP، ونتيجة التطبيق. ثبات الإحداثي لا يثبت المنع أو السماح، والسماح لا يثبت وصول الحزمة إلى صاحب صحيح، والمصافحة لا تثبت إنجاز العمل.

ليست مشكلة الفتح المتزامن

تتناول RFC 5382 كذلك TCP simultaneous open. يرسل طرفان SYN في الوقت نفسه، وتتقاطع الحزمتان، ثم تنتقل الآلتان عبر حالة صحيحة إلى اتصال واحد. فشلت بعض المترجمات لأنها اعتبرت ترتيب العميل والخادم هو الاحتمال الوحيد. لهذه القصة ومهلة الست ثوان تغطية BTW مستقلة.

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

لذلك تختلف أدلة الحادث. يحتاج الفتح المتزامن إلى تاريخ حالات TCP وترتيب الحزم. ويحتاج REQ-7 إلى إيصال تخصيص: الزوج الداخلي، والزوج الخارجي، والوجهة البعيدة، والبروتوكول، والوقت، وإصدار الخوارزمية، والعقدة المالكة للحالة. اختصار الاثنين إلى عبارة «مشكلة NAT» يزيل القرار الذي يجب إصلاحه.

الإسناد ليس أكثر يقيناً من ساعة المترجم

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

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

لا تعني REQ-7 أن العنوان العام والمنفذ يثبتان شخصاً أو فعلاً. لكنها تمنع نوعاً محدداً من الغموض المتزامن في TCP: ألا يكون للتعيين الحي صاحبان داخليان في الوقت نفسه. هذا يضع أساساً أصدق لأي استدلال لاحق.

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

الندرة لا تمنح حق تغيير معنى الدليل

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

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

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

يحق لإدارة السعة اختيار حجم الحوض وكتل المنافذ وسياسة القبول وخطة IPv6. ولا يحق لها تعريف الغموض على أنه كفاءة ثم مطالبة فرق الأدلة والعملاء بتحمل الفرق.

ما تكشفه hairpinning ورسائل ICMP

تلزم REQ-8 بدعم hairpinning في TCP، وبأن يظهر للطرف الداخلي عنوان المصدر الخارجي ومنفذه. إذا عرف طرفان داخليان بعضهما فقط من خلال التعيينات العامة، فإنهما يتوقعان أن تصل الحزمة بهوية النظير التي استخدماها. حتى المسار الذي يعود داخل الجهاز يحافظ على هذا المعنى.

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

تحدد REQ-9 وREQ-10 سلطة ICMP. ينبغي ترجمة رسائل Destination Unreachable المناسبة، لكن وصول أي رسالة ICMP لا يجوز أن ينهي التعيين أو اتصال TCP. الرسالة دليل على حدث في المسار وليست أمراً بإعدام الحالة.

والصمت ليس دليلاً تلقائياً على موت الطرف. تحدد RFC حدوداً دنيا عندما يتعذر معرفة النشاط، بينما يعالج مقال BTW آخر التباس keepalive. المهم هنا أن التعيين الذي ما زال حياً لا يتحول إلى منفذ مجاني لإعارة متزامنة بسبب قلة الحزم.

إذا عدل ALG أرقام التسلسل، فيجب أن يعالج SACK بصورة صحيحة. كل تعديل سري يضيف التزاماً بالمحاسبة. أما التحميل الزائد فيطرح سؤالاً أسبق: لأي صاحب وأي فضاء تسلسل تنتمي الحزمة؟

اختبار يحافظ على النتيجة السلبية

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

يُكرر الاختبار عند ضغط الحوض، وبعد تغيير البرنامج والسياسة، وأثناء failover. يُحفظ المصدر الداخلي، والتعيين الخارجي، والوجهة، والبروتوكول، وأوقات الإنشاء والتحديث والحذف، وإصدار المخصص، والعقدة، وحقبة الحالة. ثم ترتبط هذه السجلات بحزم SYN وSYN-ACK وACK وبنتيجة تطبيق مستقلة.

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

المصادر