strongSwan ESP-in-UDP: حين لا يوجد NAT لاكتشافه

يجيب كشف NAT عن سؤال واحد: هل تغيّرت العناوين أو المنافذ أثناء العبور؟ لا يجيب عمّا إذا كان جدار حماية يسمح ببروتوكول IP رقم 50. يمكن أن تبقى بوابات المواقع التي لا تتضمن أي ترجمة خلف سياسة تُسقط ESP الأصلي، ويجب تكوين هذا الشرط بدلًا من اكتشافه. الآلية هي ESP-in-UDP، وهي قرار لا بديل يظهر من تلقاء نفسه.

الكشف حساب على العناوين، لا فحص لجدار الحماية

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

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

لذلك فإن التغليف خاصية للاتصال الذي تكوّنه، وليس نتيجة يتفاوض عليها الطرفان انطلاقًا من سلوك الشبكة.

كيف يغيّر encap التبادل

في نشر strongSwan حديث يُدار عبر swanctl.conf، فإن ضبط encap = yes على الاتصال يؤثر في تبادل كشف NAT بحيث يستخدم الطرفان تغليف UDP لـ ESP. ثم تنتقل الحزم المحمية داخل UDP، على المنفذ 4500 عادةً، ويجب أن يتفق كلا الطرفين على هذا الترتيب.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

تلك القطعة تنتمي داخل تعريف اتصال حقيقي وليست ملفًا تعريفياً كاملًا للموقع. أبقِ عناوين الأقران والمصادقة ومحددات حركة الابن التي تشغّلها بالفعل؛ المفتاح الوحيد المضاف يغيّر طريقة تغليف البيانات المحمية، لا ما تحميه.

يشرح دليل strongSwan لاجتياز NAT هذا السلوك، بما في ذلك التفاعل مع تعويم المنافذ عند استخدام MOBIKE.

استخدم الإعداد الذي يخصّ الواجهة الخلفية لديك

لدى strongSwan واجهتان خلفيتان للتكوين، ويختلف المفتاح بينهما. اتصال swanctl.conf يأخذ encap، بينما اتصال ipsec.conf القديم يأخذ forceencaps. إن إسقاط كلمة مفتاحية من واجهة خلفية في الأخرى ينتج تكوينًا يُحمَّل دون شكوى ولا يغيّر شيئًا، وهذا أسوأ من خطأ.

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

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

تحقق من البيانات المغلّفة، لا من المنفذ فقط

التقط على البوابة أثناء تدفق الحركة المحمية، ثم قارن ذلك برؤية strongSwan نفسها:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

يظهر ESP الأصلي كبروتوكول IP رقم 50 ولا يشبه UDP إطلاقًا. يظهر ESP المغلّف كبيانات UDP على 4500 لا تكون حمولتها IKE. حركة IKE على المنفذ نفسه ليست دليلًا على التغليف، لأن MOBIKE يمكنه نقل IKE إلى هناك بينما يبقى مسار البيانات أصليًا، لذا اقرأ الحمولة لا رقم المنفذ.

ضع في الحسبان أيضًا MTU المسار. يضيف الغلاف عبئًا إضافيًا، وقد يحتاج مسار كان يحمل ESP الأصلي إلى تعديلات حين تكبر الحزم. يجب أن تكون معالجة ICMP المطلوبة جزءًا من التصميم أصلًا؛ التغليف لا يزيل ذلك الاعتماد.

اقبل التغيير عندما تكون حركة التطبيقات الجديدة داخل النفق مرئية في الالتقاط كـ ESP مغلّف عند الطرفين، وعندما تعمل الخدمة الداخلية ومسار عودتها كما ينبغي. أي شيء أقل هو تكوين يبدو صحيحًا في ملف.