AH أم ESP؟ قرارك يبدأ مما يجب أن تحميه الحزمة

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

ما يغطيه AH ولا يغطيه ESP

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

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

NAT يحوّل الاختيار إلى قيد

تعيد ترجمة العناوين كتابة المصدر أو الوجهة في رأس IP الذي تحقق منه AH للتو، فيفشل فحص التكامل عند الطرف الآخر، ويفشل كخطأ بروتوكول لا كرسالة يمكن قراءتها. لا يتحقق ESP من الرأس الخارجي، ولهذا يعمل ESP مع اجتياز NAT بينما لا يعمل AH خلف NAT. والنفق الذي يقع طرفاه خلف موجهات عادية هو أول ما يظهر فيه ذلك. لذا فالسؤال الأول ليس أي بروتوكول أقوى، بل هل يوجد مترجم بين الطرفين.

إذا وُجد، خرج AH من الحساب، وانتقل الحديث إلى ESP وخيارات خوارزمياته. وهذا قيد لا تفضيل، ولهذا موضعه أعلى القرار لا في آخره.

الوضع يضاعف السؤال

يحمي ESP في وضع النقل حمولة الطبقة العليا ويترك رأس IP كما هو؛ وفي وضع النفق يغلّف الحزمة الداخلية بأكملها، بما في ذلك رأس IP الداخلي، ويحميها. ولـ AH الوضعان نفسهما، أي أن الاختيار بين AH و ESP هو في الحقيقة أربع تركيبات قبل اختيار أي خوارزمية.

تحسم خوارزميات ESP ذات الوضع المدمج التكامل دون بروتوكول ثان. فـ AES-GCM و ChaCha20-Poly1305 تتحقق وتشفّر في بناء واحد، لذا لا تضيف إضافة AH فوقها شيئاً بينما تكلّف رأساً آخر وتفاوضاً آخر. تسمح البنية باستخدام AH و ESP معاً، والسؤال العملي هو هل يدعم بوابتك وإصدارك هذا الجمع وهل يستطيع أحد صيانته لاحقاً.

البديل الصادق لـ AH وحده

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

رؤية ESP في مقترح ليست دليلاً على التشفير أيضاً. اقرأ خوارزمية التشفير: إدخال تشفير NULL يعني التكامل فقط، وإدخال الوضع المدمج يعني الاثنين.

قرر في ثلاثة أسئلة

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

ثم تحقق مما قُبل لا مما اقتُرح. يعرض ip xfrm state بروتوكول الرابطة المثبتة ووضعها وخوارزمياتها، وأي عدم تطابق لا يثبت شيئاً على الإطلاق، وهو فشل أنظف من نفق يقوم دون الحماية التي أردتها.

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