IPsec داخل IPsec: أي العناوين يجب أن يحملها النفق الخارجي

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

نموذج البوابات الأربع

تبني البوابتان الخارجيتان A و B النفق الأول بين الموقعين. خلف A تقع البوابة الداخلية C بعنوان العبور 10.60.0.2؛ وخلف B تقع البوابة الداخلية D بعنوان العبور 10.70.0.2. تعيش شبكات التطبيقات خلف C و D، وكل عنوان في المثال غير متداخل عمدًا.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

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

كل طبقة تزيل حمايتها فقط

يشفّر C حزمة تطبيق من أجل D. النتيجة معنونة من C إلى D، وهي ما يصل إلى A. وكل ما في المصب يعتمد على إعادة الكتابة هذه.

يشفّرها A مرة أخرى من أجل B. يفكّ B تشفير الطبقة الخارجية، ويرى حزمة من C إلى D، ويعيد توجيهها وهي لا تزال مشفّرة. وتزيل D الحماية الداخلية وتسلّم حزمة التطبيق.

لذا يرى A و B نقاط النهاية الداخلية وبياناتها الوصفية، لكنهما ليسا الطرفين الذي يفكّ تشفير حمولة التطبيق. هذه خاصية حقيقية في التصميم وليست ادعاءً بأن C أو D أو مضيفات التطبيقات موثوقة.

المحددات الخارجية تسمّي البوابات الداخلية

هنا يفشل معظم هذه الإنشاءات. فبالنسبة لنفق خارجي قائم على السياسات، يجب أن تحتوي المحددات التي تتفاوض عليها على العناوين التي يتعامل معها A و B فعليًا: 10.60.0.2/32 و 10.70.0.2/32، بالترتيب الصحيح للمحلي والبعيد.

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

لا تضيّق الإذن الخارجي إلى UDP 500 أيضًا. فللاتصال الداخلي مسار بيانات خاص به يستخدم ESP أو تغليف UDP حسب ما تفاوض عليه، وعلى السياسة الخارجية أن تسمح بهذا البروتوكول.

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

إعادة التوجيه وفخ التكرار

المحددات لا تحل محل التوجيه. يجب أن يعيد A و B توجيه حركة المرور بين C و D في الاتجاهين، وهذا يعني تمكين إعادة توجيه IP، ومسارات تشير إلى النفق، ومسار عودة موجود على الجانب الآخر.

إذا كان النفق الخارجي يستخدم واجهات XFRM، فإن المسارات تختار الواجهة بينما لا تزال السياسات المتفاوض عليها تقيّد ما تحمله. فالواجهة لا توسّع ما هو محمي؛ إنها تغيّر فقط كيفية التقاط النواة للحزمة.

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

افحص الترجمة قبل إضافة الطبقات

انظر إلى أي NAT مصدري على A و B قبل ضبط أي شيء آخر. فالقاعدة التي تعيد كتابة عنوان C قبل تطبيق سياسة IPsec يمكن أن تكسر المحددات المتفق عليها، ويمكنها أيضًا تغيير ما تستقبله D على الجانب الآخر.

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

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

أثبت fail-closed وافحص MTU

اختفاء مسار ليس سياسة fail-closed بحد ذاته. فجدول آخر أو مسار افتراضي أو قاعدة سياسة يمكن أن يوفر بديلًا بهدوء، والطريقة الوحيدة للمعرفة هي إسقاط النفق الخارجي ومراقبة ما تفعله حركة التطبيقات. افعل ذلك عمدًا، داخل نافذة، بدلًا من اكتشافه بالخطأ.

اختبر ثلاث حالات: النفق الخارجي معطّل، والنفق الداخلي معطّل، والتعافي بعد عودة الاثنين. استخدم عدادات السياسات على كل بوابة، لأن جلستي IKE قائمتين تثبتان فقط أن تفاوض مستوى التحكم نجح.

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