الخلاصة

  • يسمح RFC 9611 بعدة Child SA ذات TSi/TSr متطابقة كي يحتفظ كل معالج أو صف بمفاتيحه وتسلسله، بدل مزامنة عداد تشفيري واحد.
  • يعلن SA_RESOURCE_INFO عضوية المجموعة، وتبقى بياناته الاختيارية للتصحيح فقط. ولا يوجّه معالج الطرف الآخر. أما TS_MAX_QUEUE فيرفض مزيدًا من الأعضاء لتلك المحددات وحدها.
  • لا تثبت المفاوضة السعة؛ يجب إثبات التثبيت في الاتجاهين، والربط المحلي، وتوزيع الرزم، وعدادات الإعادة والفقد، وإعادة المفتاح، والحذف والعودة، ثم الخدمة المستلمة.

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

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

يجب أن تتطابق الخوارزميات وTSi/TSr والنمط والضغط. هذه حدود الاتفاق. أما المورد المحلي وتوزيع الرزم فليسا جزءًا من سلطة الطرف البعيد.

معرّف المورد ليس خريطة عتاد

يمكن أن يحمل SA_RESOURCE_INFO قيمة تميّز أعضاء المجموعة، لكن على الطرف استخدامها للتصحيح فقط. رقم CPU الحقيقي قد يكشف أي الرزم يعالجها أي مورد ويساعد على الاستهداف. كما أن اسم صف محلي لا يحمل معنى تشغيليًا عند الطرف الآخر.

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

الاستقلال يزيل قفلًا واحدًا

يربط RFC 4303 تسلسل ESP بمنع الإعادة، ويقدم RFC 6479 سياق نافذة الاستقبال. لا يلغي RFC 9611 هذه الحالة؛ بل يقسمها إلى مجالات صحيحة مستقلة.

المثال الذي ارتفع من نحو 5 غيغابت/ث على CPU واحد إلى 40–60 على 25–30 CPU يشرح الدافع، ولا يضمن منتجًا آخر. تختلف النتيجة مع NIC والخوارزمية وبرنامج التشغيل وحجم الرزم ومزيج التدفقات. يجب قياس الرزم والبايتات لكل SA، واستعمال الموارد، وأخطاء السلامة والإعادة، والفقد والزمن ومعدل التطبيق.

التزام الاستقبال لا يساوي حاجة الإرسال

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

إذا احتاجت البوابة لاحقًا إلى النصف الصادر المحذوف، فقد تحتاج مادة مفاتيح كان برنامج IKE سيزيلها. لذلك يرتبط قرار نقل المورد بسياسة عمر المفاتيح.

الحالة المؤقتة أكبر من الحالة المستقرة

قد يبدأ الطرفان إنشاء SA في الوقت نفسه. تعبر الرزمة المحفزة الارتباط الأول، وقد يشغّل ردها طلبًا معاكسًا. وفي rekey تتعايش الارتباطات الجديدة والقديمة. لهذا يوصي RFC 9611 بسعة لا تقل عن ضعف عدد المعالجات بدل حد جامد مساوٍ لها.

عند بلوغ حد TSi/TSr، يصف TS_MAX_QUEUE النطاق الصحيح. أما NO_ADDITIONAL_SAS فقد يُفهم كرفض لارتباطات ذات محددات أخرى.

الحذف يحتاج أيضًا إلى طريق عودة. إذا لم يحمل المشغّل المحلي هوية CPU أو الصف، فقد لا يعرف النظام متى يعيد SA. الإعادة الفورية قد تنشئ حلقة حذف وإنشاء، وعدم الإعادة يترك الطرفين على الارتباط الأول. يوفر RFC 2367 سياق SADB_ACQUIRE الذي ينبغي إثراؤه محليًا.

يناسب هذا الأسلوب بوابات عالية الحجم بين إدارتين موثوقتين. تستهلك الارتباطات الكثيرة حالة وقد تبطئ بحث SAD. وفي VPN للوصول البعيد يستطيع عملاء أقل ثقة تضخيم الحالة؛ لذلك لا يوصي RFC 9611 بالوضع لكل CPU أو بتفعيله افتراضيًا هناك.

المصادر