strongSwan على EC2: اجعل VPC يوجّه عبء العمل

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

اكتب العناوين الأربعة أولًا

كل خطوة أدناه تشير إليها، لذا املأها لحسابك قبل لمس جدول توجيه.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

يفترض المثال اتصال IPsec قائمًا ومعتمدًا قائمًا على السياسات، وتدفقًا يحافظ على المصدر. هذا ليس عميل وصول بعيد خلف NAT يستعير عنوانًا واحدًا مخصصًا، وهذا الفرق يحدد ما إذا كان يجب تغيير المحددات.

الخطوة 1: أعطِ الشبكة الفرعية لعبء العمل مسارًا

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

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

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

الخطوة 2: فعّل إعادة التوجيه على الضيف

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

مجموعات الأمان هي حيث تتوقف هذه الخطوة عادة. لا يرث الجهاز الوسيط سلوك مرجع مجموعة الأمان الخاص بالتواصل المباشر بين النسخ، لذا قد لا تطابق أبدًا قاعدة منسوخة من مثال Client VPN مُدار. افحص مجموعة الأمان وقائمة ACL للشبكة الفرعية على المسار الفعلي، في الاتجاهين.

الخطوة 3: وسّع المحددات إلى المصادر الحقيقية

سياسة تغطي فقط 10.60.1.10/32 على جانب AWS تفسر نجاحًا انطلق من البوابة دون تغطية 10.60.2.20. المسار نحو الوجهة البعيدة لا يوسّع محدد حركة، وذلك هو النصف الثاني من المفاجأة نفسها.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

إذا كان التصميم المتفق عليه يحمي VPC بأكملها، فعلى الطرفين قبول 10.60.0.0/16 و 10.90.0.0/24. وإذا كان يحمي عبء عمل واحد، فاستخدم تلك البادئة الأضيق عن قصد. في كل الأحوال، افحص سياسة CHILD-SA المثبتة، لأن إعدادًا حررته وطرفًا ضيّقه بشكل مختلف ليسا الاتفاق نفسه.

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

الخطوة 4: تحقق، ثم ارجع عند الحاجة

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

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

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