تؤمن حزمة بروتوكولات IPsec حركة البيانات في طبقة الشبكة عبر البنى التحتية العامة غير الموثوقة. وعند تطوير هذه المعايير في البداية، كان الافتراض السائد هو امتلاك جميع الأجهزة المتصلة بالإنترنت عناوين IPv4 عامة وقابلة للتوجيه المباشر. ويعتمد بروتوكول أمان البيانات المشفرة (ESP المخصص برمز البروتوكول 50) على توفير السرية والتحقق من مصدر الحزم ومقاومة هجمات إعادة الإرسال. غير أن استنزاف عناوين IPv4 أدى إلى الاعتماد الواسع على تقنيات ترجمة عناوين ومنافذ الشبكة (NAT/PAT). وبما أن بروتوكول ESP المجرد يعمل مباشرة فوق طبقة بروتوكول الإنترنت دون منافذ لطبقة النقل (TCP/UDP)، فإن البوابات الوسيطة تعجز عن تتبع حركة البيانات المشفرة العائدة أو فرزها. وتقدم وثيقتا RFC 3947 و RFC 3948 حلاً معمارياً جذرياً عبر تغليف حزم ESP داخل رسائل بروتوكول UDP الموجهة عبر المنفذ 4500.

بنية ESP المجرد (فشل التوجيه عبر بوابات PAT/NAT):
[ترويسة IP (رمز 50)] [ترويسة ESP: رمز SPI (٤ بايت), تسلسل (٤ بايت)] [بيانات مشفرة]
                      └──> غياب منافذ UDP/TCP! تعجز بوابة PAT عن توجيه حزم الرد.

تغليف ESP وفق معيار RFC 3948 (عبر منفذ UDP 4500):
[ترويسة IP (رمز 17)] [ترويسة UDP (مصدر 4500, وجهة 4500)] [ESP] [بيانات مشفرة]
                      └──> توفر منافذ الطبقة الرابعة يتيح تتبع حالة الجلسات بدقة.

معضلة ترجمة منافذ PAT: أسباب إخفاق بروتوكول ESP المجرد عبر NAT

يتطلب إدراك الضرورة الحتمية لتقنية تمرير IPsec عبر NAT تحليلاً دقيقاً لكيفية معالجة بوابات الترجمة ذات التتبع لحزم البيانات.

غياب منافذ طبقة النقل: افتقار ترويسة ESP لمنافذ TCP/UDP

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

يعمل بروتوكول ESP ضمن الطبقة الثالثة ويحمل الرمز 50. وخلافاً لميفاق TCP أو ميفاق UDP، لا يمتلك بروتوكول ESP أي مفهوم لأرقام المنافذ. وتحتوي أول 4 بايت من ترويسة ESP على مؤشر معاملات الأمان (Security Parameter Index أو SPI)، وهو قيمة من 32 بت يحددها الطرف المستقبل للتعرف على رابطة الأمان (SA):

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Security Parameters Index (SPI)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Payload Data (Variable)                    |

حين تجتاز حزمة ESP خارجة بوابة PAT، يعيد الموجه كتابة عنوان IP المصدر دون أن يتمكن من إنشاء سجل منفذ في جدول الجلسات. وعند عودة الحزم، تفحص البوابة الترويسة فتجد غياباً لمنفذ الوجهة، مما يمنعها من تحديد الوجهة الداخلية الصحيحة. ورغم اعتماد بعض الموجهات أسلوب تمرير SPI التقريبي، ينهار هذا الحل بمجرد اتصال عدة أجهزة محلية بالخادم البعيد نفسه.

تعديل مسار الحزمة وبطلان المجموع الاختباري لميفاقي TCP/UDP

تظهر عقبة أخرى في نمط النقل (Transport Mode) لبروتوكول IPsec. تعتمد خوارزميات فحص المجموع الاختباري في الترويسات الزائفة لميفاقي TCP و UDP على التحقق من صحة عنوان المصدر وعنوان الوجهة ونوع البروتوكول وطول القطعة. وعندما تبدل بوابة NAT عنوان IP أثناء العبور، تصبح قيمة المجموع الاختباري الأصلية باطلة. وبسبب تشفير محتوى الحزمة بالكامل بواسطة ESP، لا تستطيع البوابة الوسيطة إعادة احتساب المجموع الاختباري. وخلال فك التشفير عند المستلم، يفشل التحقق من صحة الحزمة، مما يدفع نواة نظام التشغيل إلى التخلص منها بصمت.

آلية RFC 3947 NAT-Discovery: الاستكشاف الديناميكي للبوابات الوسيطة

للتعامل التلقائي مع هذه التحديات، تحدد وثيقة RFC 3947 (المدمجة في بروتوكول IKEv2 وفق RFC 7296) آلية الكشف التلقائي عن وجود NAT خلال المراحل الأولى لإنشاء روابط الأمان.

حمولات NAT-D ومقارنة نواتج التجزئة أثناء تفاوض IKE_SA_INIT

خلال المرحلة الابتدائية (IKE_SA_INIT)، يتبادل العميل والخادم الحزم عبر منفذ UDP 500 المعتاد. يرسل كل طرف حمولات تسمى NAT-D (حمولة كشف NAT)، تحمل ناتج تجزئة مشفرة لعناوين ومنافذ أطراف الاتصال:

$$\text{NAT-D Hash} = \text{SHA-1}(\text{SPI}_i ,|, \text{SPI}_r ,|, \text{IP} ,|, \text{Port})$$

١. يحتسب الطرف البادئ ناتج تجزئة عنوانه ومنفذه المحلي، وناتج تجزئة عنوان الخادم، ثم يرسلهما في الحزمة. ٢. يحتسب الطرف المستقبل نواتج التجزئة للعناوين المرصودة فعلياً عند استلام الحزمة. ٣. في حال تطابق القيم المرسلة مع القيم المحتسبة، يستنتج الطرفان خلو المسار من بوابات الترجمة. ٤. إذا ظهر أي تباين، يؤكد ذلك وجود بوابة وسيطة غيرت العنوان الخارجي أثناء العبور.

تعويم المنفذ: الانتقال السلس من منفذ UDP 500 إلى UDP 4500

بمجرد التحقق من وجود ترجمة للعناوين عبر آلية NAT-D، ينتقل البروتوكول فوراً إلى تعويم المنفذ (Port Floating). فابتداءً من رسالة IKE_AUTH اللاحقة، يحول الطرفان جميع الاتصالات من المنفذ 500 إلى المنفذ 4500.

يمنع هذا التحول المشاكل الناتجة عن قيام بعض الجدران النارية بحظر أو تقييد جلسات UDP 500 المتعددة، كما يمهد القناة لنقل حزم التحكم وحزم البيانات المشفرة معاً عبر المنفذ نفسه.

بنية التغليف وفق RFC 3948: دور علامة Non-ESP بطول 4 بايت

تكمن الصعوبة الكبرى في استخدام المنفذ 4500 المشترك في ضرورة استقبال رسائل إدارة IKE وحزم ESP المشفرة في آن واحد. وقد عالجت وثيقة RFC 3948 هذه المسألة بدقة عالية عبر حقل العلامة.

فرز حركة التحكم في تبادل المفاتيح IKE عن حمولة بيانات ESP

عند وصول حزمة إلى منفذ UDP 4500، يتعين على بنية IPsec فرز الحزمة فوراً: هل تمثل رسالة تحكم إدارية (يجب توجيهها إلى تطبيق الإدارة في مساحة المستخدم) أم حزمة بيانات مشفرة (يجب تسليمها لمعالجات التشفير في النواة)؟

يتم إنجاز هذا التمييز بفحص حقل Non-ESP Marker بطول 4 بايت:

رسالة تحكم IKE عبر UDP 4500 (تحتوي علامة Non-ESP):
+---------------------------------------------------------------+
| ترويسة UDP (منفذ المصدر: متغير، منفذ الوجهة: 4500)            |
+---------------------------------------------------------------+
| علامة Non-ESP: القيمة 0x00000000 (أربعة بايتات صفرية)         |
+---------------------------------------------------------------+
| ترويسة رسالة IKEv2 (مؤشرات التبادل ومعاملات الأمان)           |
+---------------------------------------------------------------+

حزمة بيانات ESP مشفرة عبر UDP 4500 (بدون علامة صفرية):
+---------------------------------------------------------------+
| ترويسة UDP (منفذ المصدر: متغير، منفذ الوجهة: 4500)            |
+---------------------------------------------------------------+
| قيمة ESP SPI (٣٢ بت، قيمة غير صفرية قطعاً: 0xXXXXXXXX)       |
+---------------------------------------------------------------+
| رقم تسلسل الحزمة ESP (٣٢ بت)                                  |
+---------------------------------------------------------------+
| البيانات المشفرة وحقل التحقق التكاملي ICV                     |
+---------------------------------------------------------------+

تنص مواصفات RFC 4303 على أن أول 4 بايت من حزمة ESP مخصصة لحقل SPI، وتعتبر القيمة 0x00000000 محظورة ومحجوزة بحيث لا تُمنح لرابطة أمان نشطة أبداً. وبناءً على ذلك، إذا كانت البايتات الأربعة التالية لترويسة UDP أصفاراً، تدرك النواة أنها رسالة IKE وتحيلها إلى الخدمة الإدارية؛ أما إذا كانت القيمة غير صفرية، فتعامل فوراً كمعامل SPI لحزمة ESP وتُفك شفرتها مباشرة في النواة.

آلية الحفاظ على الاتصال NAT Keepalive ومؤقتات جداول الترجمة

تحفظ بوابات NAT معلومات الجلسات في جداول مؤقتة. فإذا توقفت حركة البيانات لفترة وجيزة، تحذف البوابة سجل الترجمة بعد انقضاء المهلة الزمنية (المحددة بين 30 إلى 120 ثانية في شبكات الهاتف المحمول). وبمجرد مسح السجل، تعجز الحزم الواردة من الخادم عن الوصول للعميل.

ولمنع هذا الانقطاع، حددت مواصفات RFC 3948 إرسال حزم الحفاظ على الجلسة دورياً، حيث يرسل العميل حزمة UDP موجزة جداً:

+-----------------------------------------------+
| ترويسة IP (برمز 17، عناوين الاتصال)          |
+-----------------------------------------------+
| ترويسة UDP (مصدر 4500، وجهة 4500، طول 9 بايت) |
+-----------------------------------------------+
| القيمة 0xFF (بايت مفرد للحفاظ على الجلسة)     |
+-----------------------------------------------+

عند استلام الحزمة ذات البايت المفرد 0xFF، تجدد البوابة الوسيطة مؤقت نشاط الجلسة وتسقط هذا البايت دون تسجيل أخطاء، مما يضمن استمرار فتح قناة التوجيه دون انقطاع.

العبء الإضافي للتغليف، واكتشاف أقصى وحدة نقل Path MTU وضبط TCP MSS

يؤدي التغليف الإضافي لحزم ESP داخل بروتوكول UDP إلى زيادة في حجم الترويسات، مما يستدعي ضبطاً ملائماً لمعاملات وحدة النقل.

يقلل إلحاق ترويسة UDP المكونة من 8 بايتات الحجم الفعلي المتاح لنقل البيانات. ففي وصلة إيثرنت قياسية بسعة 1500 بايت:

  • يتراوح العبء الإضافي لحزم IPv4 ESP العادية بين 50 إلى 60 بايت بحسب خوارزمية التشفير (مثل خوارزميات AES-GCM أو تكامل AES-CBC مع مصفوفات HMAC).
  • يضيف تغليف UDP ما مقداره 8 بايتات إضافية، ليرتفع إجمالي العبء إلى ما بين 62 و 72 بايت.
  • ينبغي ضبط الحد الأقصى لحجم مقطع البيانات (TCP MSS) وخفضه من القيمة الافتراضية 1460 بايت إلى نطاق يتراوح بين 1360 و 1380 بايت.

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

الصمود في شبكات CGNAT المؤسسية: التكامل ضمن بيئة RiceGuard

يطبق محرك RiceGuard المعتمد في VPNRice معايير RFC 3948 لتوفير اتصال متين عبر شبكات الهواتف المعقدة وبيئات الجدران النارية المزدوجة.

بنية أنفاق انعدام الثقة في RiceGuard:
الأجهزة المحمولة / المحطات البعيدة
  │  (خلف بوابات CGNAT أو شبكات الترجمة المزدوجة)
  │  تبدأ تفاوض IKE_SA_INIT عبر منفذ UDP 500
  ▼
التحقق التلقائي من مؤشرات NAT-D
  │  - رصد أي تبدل في عناوين الاتصال الخارجية
  │  - تعويم فوري للمنفذ إلى UDP 4500
  │  - تزويد رسائل التحكم بعلامات Non-ESP ذات 4 بايت
  ▼
بوابات RiceGuard الفائقة
  │  - استقبال تدفقات ESP المغلفة في UDP 4500
  │  - إدارة روابط SAD عبر تسريع نواة لينكس XFRM
  │  - تكييف معدلات حزم الحفاظ على الجلسة آلياً
  ▼
شبكة الاتصال المؤسسي المشفرة / تصفح الإنترنت

١. تعويم حتمي للمنافذ: يتعرف نظام RiceGuard على وجود وسائط الترجمة منذ اللحظة الأولى، وينتقل للمنفذ 4500 لتفادي القيود المفروضة على المنفذ 500 لدى مزودي الخدمة. ٢. جدولة متكيفة لحزم الحفاظ: يعتمد النظام فترات ديناميكية لإرسال حزم التنشيط بما يتماشى مع طبيعة الشبكة، للمحافظة على طاقة بطاريات الهواتف المحمولة. ٣. معالجة سريعة عبر النواة: يتيح توظيف مقابس XFRM في نواة لينكس توجيه الحزم المشفرة مباشرة إلى وحدات العتاد المسرعة لتفادي أي تباطؤ.

التحقق التشخيصي: فحص مقابس NAT-T وقاعدة SAD داخل نواة لينكس

يستطيع مسؤولو الشبكات التأكد من عمل جلسات NAT-T النشطة على خوادم لينكس باستخدام الأدوات المدمجة في النظام.

فحص حالة الاستماع لمقابس UDP 4500

التحقق من بقاء مقابس بروتوكول IPsec في وضع الاستماع على المنفذين 500 و 4500:

# التحقق من مقابس استماع UDP لخدمات IKE و NAT-T
ss -uan '( sport = :500 or sport = :4500 )'

النتيجة المتوقعة:

State    Recv-Q    Send-Q       Local Address:Port        Peer Address:Port
UNCONN   0         0                  0.0.0.0:500              0.0.0.0:*
UNCONN   0         0                  0.0.0.0:4500             0.0.0.0:*

استعراض حالة ارتباطات XFRM ومعاملات تغليف UDP في النواة

فحص قاعدة بيانات روابط الأمان (SAD) للتأكد من تفعيل معاملات التغليف:

# عرض معاملات روابط أمان IPsec النشطة وتفاصيل التغليف
ip xfrm state show

مقتطف من الناتج:

src 198.51.100.2 dst 203.0.113.1
	proto esp spi 0xc7a41289 reqid 1 mode tunnel
	replay-window 64 flag af-unspec
	auth-trunc hmac(sha256) 0x6e7a... 128
	enc cbc(aes) 0x4f12...
	encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
	sel src 0.0.0.0/0 dst 0.0.0.0/0

تؤكد العبارة encap type espinudp أن نواة لينكس تغلف حزم ESP الصادرة داخل ترويسات UDP بالمنفذ 4500، وتستقبل الحزم المتوافقة بالصيغة ذاتها لضمان مرور سلس دون عوائق.

مثّل معيار RFC 3948 نقلة محورية ضمنت استمرار فاعلية بروتوكولات IPsec عبر شبكات الإنترنت المعاصرة. ومن خلال التغليف القياسي عبر المنفذ UDP 4500 واستخدام علامة Non-ESP، تحتفظ الاتصالات المشفرة بمستويات عالية من الكفاءة والاستقرار عبر شبكات المشغلين والبيئات المؤسسية.

لإنشاء أنفاق موثوقة قائمة على انعدام الثقة وتمر بسلاسة عبر البوابات المؤسسية، تحميل VPNRice.