الخلاصة

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

قد تنجح مفاوضة النفق فيما لا تصل البيانات التي يفترض أن يحميها. لا تناقض هنا: IKEv2 ينشئ الروابط الأمنية ويديرها، أما ESP فيحمل الحزم المحمية. تتيح المقترحات قيد البحث استخدام TCP لتبادل رسائل IKE الكبيرة، مع إبقاء ESP على IP مباشرة أو داخل UDP حيث تسمح الشبكة. في المقابل قد تفرض الأجهزة الوسيطة سياسات وترجمات عناوين ومهلاً مختلفة على المسارين؛ لذلك لا يكفي اختبار اتصال التحكم للحكم على مسار البيانات.

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

لم تُبتكر فكرة الفصل بين النقلين في النسخة 08. فقد تضمنت النسخ السابقة إشعار SEPARATE_TRANSPORTS: يستطيع المبادر بدء IKE_SA_INIT عبر UDP على المنفذ 4500 ثم تحويل التبادلات اللاحقة إلى TCP إذا رد الطرف الآخر بالإشعار. ويمكنه البدء عبر TCP مباشرة إذا كان التبادل الأول كبيراً. بعد التفاوض على الفصل يسلك ESP مسار IP أو UDP إذا أمكن؛ وإذا بدأ IKE على TCP ولم يؤكد الطرف الآخر الإشعار، تستخدم رسائل IKE وحزم ESP معاً TCP وفق آلية RFC 9329 القائمة. هذه خلفية ضرورية لفهم الحد الجديد، وليست تطوراً مستحدثاً في هذه المراجعة.

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

وكان النص يفرق أصلاً بين حالتي NAT: اتصال TCP المستخدم لـIKE لا يحافظ على تعيين UDP الخاص بـESP؛ وعلى مسار ESP إرسال رسائل الإبقاء اللازمة بنفسه. وعندما تبدأ مفاوضة IKE عبر TCP، لا تنشأ من نجاحها قرينة ضمنية على وصول ESP. بعد إنشاء الرابطة الفرعية ينبغي للمبادر اختبار مسار ESP ما لم تتوفر له قرينة أخرى؛ وإذا تعذر التأكد، فعليه حذف رابطة IKE وإعادة إنشائها عبر TCP من دون اقتراح نقل ESP منفصل. الانتقال هنا جواب لنتيجة اختبار البيانات، لا لمجرد نجاح المصافحة.

يعرض Datatracker الوثيقة بوصفها Internet-Draft نشطة صادرة عن مجموعة العمل، طُلب نشرها وقُدمت للنظر في ذلك؛ وليست RFC منشورة. كما أن قيمة الإشعار ما زالت غير مخصصة في نص المسودة. لا تثبت المصادر التي فُحصت انتشار التنفيذ أو وقوع انقطاع لدى منتج بعينه. الخبر المحدد هو تضييق حدود ما تسمح به إشارة التحكم وتخفيف اليقين المنسوب إلى غياب البيانات.

المصادر