الخلاصة

  • تسمح المراجعة 07 بأن يعمل IKEv2 على TCP بينما يُنقل ESP مباشرة فوق IP أو داخل UDP، غير أن إنشاء Child SA صحيحة لا يثبت أن مسار ESP قابل للوصول.
  • يجب فصل أدلة التفاوض، وحالة NAT لكل ناقل، واستجابة ESP المشفرة، وحركة التطبيق، وقرار الرجوع؛ فقد تبقى المصادقة سليمة فيما تكون الخدمة غائبة.

تبدأ المشكلة بلوحة تبدو مطمئنة: اتصال TCP قائم، والطرفان تصادقا، والمفاتيح اشتُقت، وظهرت Child SA في الحالة المحلية. كل ما يخص قناة التحكم يقول إن العمل اكتمل. ثم لا تصل أي حركة مفيدة.

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

هذه هي الحدود التي تعالجها مسودة IPsecME النشطة Separate Transports for IKE and ESP. المراجعة 07 Internet-Draft في مسار IETF ومقصودة لـStandards Track، وحالتها المجمدة في Datatracker هي “WG Consensus: Waiting for Write-Up”. ليست RFC ولا سجل نشر أو اختبار توافق.

يأتي التصميم من ضغطين. يستخدم IKEv2 تقليديًا UDP، فيما يتيح RFC 9329 وضع IKE وESP معًا داخل TCP عندما يُحجب UDP. وفي المقابل تكبر رسائل التبادل مع خوارزميات ما بعد الكم، فيصبح TCP مناسبًا لبيانات التحكم الكبيرة. لكن حمل كل حركة ESP داخل TCP قد يضيف تكلفة أداء وسلوك ازدحام غير مرغوب.

تقترح المراجعة 07 إشعار SEPARATE_TRANSPORTS. إذا قبله الطرفان، تستمر رسائل IKE اللاحقة عبر TCP، فيما يستخدم ESP بروتوكول IP مباشرة أو تغليف UDP عند وجود NAT. وإذا لم يُرجع المستجيب الإشعار، يبقى IKE وESP معًا على TCP وفق RFC 9329.

الإشعار اتفاق قدرة، لا شهادة عبور.

إذا بدأ IKE_SA_INIT عبر UDP، فإن الطلب والرد يقدمان ضمنيًا دليلًا محدودًا على وصول UDP. أما إذا بدأ عبر TCP فلا يوجد دليل ضمني على ESP. لذلك ينبغي للمبادر، بعد إنشاء Child SA، أن يتحقق من مسار ESP ما لم يكن لديه دليل آخر مثل حركة ESP واردة.

وتفصل المسودة بين حكمين أمنيين. تعذر تأكيد ESP لا يضعف بذاته مصادقة IKEv2 ولا الحماية التشفيرية للـChild SA. قد تكون الهوية صحيحة والمفاتيح صحيحة، بينما لا تتوافر الخدمة. وصف الحالة بأنها فشل مصادقة يضلل التحقيق، ووصفها بأنها نفق عامل يبالغ في الإثبات.

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

هوية واحدة لا تعني ذاكرة طريق واحدة.

عند بدء IKE على TCP، تحدد المراجعة اختبارًا واضحًا. إذا اكتُشف NAT، يُختبر ESP المغلف في UDP على 4500. وإذا لم يُكتشف، يُجرّب ESP المباشر أولًا، ثم UDP بعد انتظار قصير بلا رد لأن بعض الوسطاء يرفضون IP الذي لا يحمل UDP أو TCP. يُختار أول مسار يستجيب، بمنطق قريب من Happy Eyeballs.

يمكن استخدام Encrypted ESP Echo للحصول على هذا الإيصال. لكنه يثبت سؤالًا محدودًا: طلب ESP محمي ورد محمي عبرا هذا المسار تحت هذه SA. لا يثبت كل أحجام الحزم أو كل Traffic Selectors أو صحة الخدمة خلف النفق أو اكتمال معاملة المستخدم. بعد الاختبار الشبكي يلزم اختبار تطبيق ممثل.

إذا لم يمكن تأكيد ESP، يجب حذف IKE SA الحالية بواسطة DELETE payload ثم إنشاؤها من جديد عبر TCP من دون اقتراح فصل ESP. يعود النظام بذلك إلى حمل IKE وESP معًا وفق RFC 9329. وتقرر السياسة المحلية هل تقبل ESP فوق TCP أم توقف الإنشاء. قد تقبل قناة إدارة طارئة تكلفة الأداء، بينما ترفضها خدمة حساسة للتأخير.

تغيّر العنوان عبر MOBIKE يعيد فتح السؤال. المسار الجديد يملك مرشحات وتعيينات جديدة، واستمرار IKE على TCP لا ينقل دليل ESP القديم. كما أن استئناف الجلسة لا ينبغي أن يخزن اختيار النقل؛ فقد يكون العميل انتقل إلى شبكة أخرى أثناء غيابه، ولذلك يُعاد التفاوض.

ينسجم ذلك مع طرح Heng Lu حول الحد الأدنى للمواصفة والقرار المستقبلي المحلي. يتشارك الطرفان القدرة الضرورية فقط، ثم يقرر الطرف الذي يرى الواقع الحالي بين ESP المباشر وUDP وTCP أو الإيقاف. عبارة “SA established” حقيقة رمزية وتشفيرية، وليست بديلًا عن الحزم المحمية التي تحركت فعلًا. أولوية running code تعني مراقبة التنفيذ، لا الثقة في ملصق الحالة.

يجب أن يسجل التشغيل على نحو مستقل: ناقل IKE، وقبول الإشعار، ونتيجة NAT، ومسار ESP المجرب، وتعيينه وkeepalive، وأول رد محمي، وحركة التطبيق، والجهة التي أجازت الرجوع، وإعادة التحقق بعد الحركة أو الاستئناف. عبارة «VPN يعمل» تمحو الحدود التي تحتاجها المساءلة.

المصادر