من strongSwan إلى AWS Site-to-Site: لماذا لا يختار Child SA شيئًا

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

ترجم أسماء AWS إلى مصطلحات strongSwan

يصف AWS الاتصال من جانب العميل: عنوان بوابة العميل وCIDR المحلي ملكك، أما CIDR البعيد فهو ملك VPC. ويسمي strongSwan الطرفين left وright، بحيث تكون بادئتك في leftsubnet وبادئة VPC في rightsubnet. وعكس أحد الزوجين ينتج نفقًا يتفاوض على حركة المرور الخطأ ويختارها.

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

عدم التطابق هنا يبدو كفشل في التوجيه وليس كذلك.

ثبّت العنوان الذي يراه AWS فعليًا

قد يُصدر موجّه خلف NAT حزم IKE من واجهة لم يعرفها الطرف الآخر قط. ويجب أن يكون عنوان البوابة المسجل في AWS هو نفسه الذي يلاحظه AWS على السلك، كما يجب تثبيت الموجّه على العنوان المحلي نفسه بدل اتباع مساره الافتراضي.

conn %default
    local_addrs = 203.0.113.10

في strongSwan يحدد local_addrs عنوان المصدر لحزم IKE، وتكتب إعدادات OpenSwan الأقدم الفكرة نفسها باسم left. وجّهه إلى الواجهة التي تحمل العنوان العام، ثم تحقق على جهاز NAT نفسه من أن UDP 500 و4500 تصل إلى ذلك المضيف، لأن قاعدة متبقية من موجّه سابق تُسقطها بصمت. ويظل زوج المحدِّدات الصحيح مع عنوان مصدر خاطئ فاشلًا، وسيحمّل السجل اللوم على المقترح. هذا التضليل هو سبب استحقاق عنوان المصدر لفحص خاص به.

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

تعامل مع المرحلة 1 والمرحلة 2 بشكل منفصل

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

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

الصياغة لا تنتقل بين التطبيقات. فزوج يعمل في OpenSwan، مثل phase2alg=aes_gcm مع ike=aes256-sha1;modp1024، يحتاج إلى ترجمة إلى صيغة esp= وike= في strongSwan، وأسماء الخوارزميات مختلفة. ولأن GCM يواثق أثناء التشفير، فهو لا يحتاج تحويل سلامة منفصلًا، بخلاف مجموعة CBC المقترنة بـ SHA. وسطر المرحلة 2 المنسوخ من خدمة إلى أخرى دون ترجمة ينتج رفضًا يبدو كعدم تطابق في المحدِّدات.

افحص رابطة الطفل، لا مؤشر النفق

إذا حُمّل الاتصال دون أن يظهر طفل، فقد رُفض المقترح أو المحدِّدات. وإذا ظهر طفل واستبعدت محدِّداته بادئاتك، فتُرشَّح الحزم قبل أن تصل إلى النفق. ومؤشر وحدة التحكم يغطي مستوى IKE فقط، لذا لا يمكنه إخبارك أي الأمرين حدث.

ipsec statusall

ابحث عن رابطة الأمان للطفل واقرأ محددات حركة المرور المطبوعة بجانبه، ثم قارنها بالبادئات من الإعداد المولّد.

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

عندما يستمر الفشل بعد تطابق المحدِّدات

أكّد أن المسار على الجانبين يشير إلى النفق، ثم أكّد أن جهاز NAT لا يعيد كتابة حركة المرور بطريقة لا تتوقعها السياسة. فالنفق القائم على السياسة يطابق عناوين الحزم، لذا فإن ترجمة تُطبَّق بعد قرار السياسة تغيّر النتيجة.

سجّل حزمة داخلة وحزمة خارجة على كل جانب قبل تغيير أي مقترح آخر.

سجّل المحدِّدات ومقترحي المرحلة 1 والمرحلة 2 وعنوان المصدر في التذكرة. هذه القيم الأربع تفسر معظم إخفاقات الربط بين المواقع دون مكالمة.