strongSwan روی EC2: بگذارید VPC بار کاری را مسیریابی کند

تونل برپاست، نمونه دروازه می‌تواند شبکه دور را پینگ کند، اما نمونه برنامه کنارش به هیچ چیز نمی‌رسد. هیچ چیز خراب نیست. آزمون موفق از میزبان 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: انتخابگرها را تا مبدأهای واقعی گسترش دهید

سیاستی که در سمت AWS فقط 10.60.1.10/32 را پوشش می‌دهد، موفقیتی را که از دروازه آغاز شده توضیح می‌دهد بدون پوشش 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: بررسی کنید و در صورت نیاز بازگردانید

از خود بار کاری با یک عملیات برنامه تازه و مجاز آزمایش کنید، سپس با مقصدی که باید حذف شود تکرار کنید. نشانی مبدأیی که سرویس دور می‌بیند و مسیر بازگشتی که استفاده می‌کند را ثبت کنید. پینگ دروازه یا وضعیت سبز IKE آن آزمون نیست.

اگر بار کاری همچنان شکست می‌خورد در حالی که دروازه کار می‌کند، گام‌ها را به ترتیب عقب بروید: انتخابگر، سپس ارسال و گروه‌های امنیتی، سپس جدول مسیریابی مرتبط. هر یک نشانه متمایزی دارد و حدس زدن از آن یکی که واقعاً غلط است می‌گذرد.

بازگردانی همان ترتیب را برعکس می‌کند. مسیر زیرشبکه بار کاری را آخر از همه بردارید، پس از بازگرداندن انتخابگرهای پیشین، تا زیرشبکه‌ای باقی نگذارید که به دروازه‌ای اشاره کند که دیگر از مبدأهایش محافظت نمی‌کند. میزبانی شخصی می‌تواند بیش از میزبان دروازه را خدمت کند وقتی این قراردادها برقرارند، و Site-to-Site VPN مدیریت‌شده توسط AWS مدل عملیاتی دیگری است که در آن strongSwan می‌تواند به‌جای آن در سمت دروازه مشتری بنشیند.