AWS Site-to-Site VPN به NAT Gateway: VGW یا Transit Gateway

همه بار اول همان نمودار را می‌کشند: VPN به VPC، NAT gateway به اینترنت، تمام. اما AWS وقتی VPN روی virtual private gateway پایان می‌یابد این مسیر را پشتیبانی نمی‌کند، و خطا آن‌قدر بی‌صدا است که تیم‌ها بیش از یک بار آن را از نو می‌سازند. طراحی‌ای که کار می‌کند به transit gateway نیاز دارد و این، gateway و جدول‌های مسیر را در هر دو طرف تغییر می‌دهد. پیش از هر ترسیمی دو شکل را مقایسه کنید.

توپولوژی‌ای که بدیهی به نظر می‌رسد و پشتیبانی نمی‌شود

مستندات NAT gateway در AWS خطی می‌کشد که هر کسی را که فقط طراحی‌های تک‌VPC ساخته شگفت‌زده می‌کند: ترافیک اتصال Site-to-Site VPN از طریق virtual private gateway به NAT gateway مسیریابی نمی‌شود. نوع gatewayایی که VPN روی آن پایان می‌یابد تعیین می‌کند اصلاً مسیر ترجمه‌ای وجود دارد یا نه. این خطا می‌ماند چون وضعیت تونل UP است و یک نمونه EC2 در همان subnet بدون مشکل به اینترنت می‌رسد. هیچ‌یک از این دو مشاهده جهتی را که خراب است نمی‌سنجد.

در عمل بسته با نشانی مبدأ از شبکه محلی می‌رسد و هیچ گام بعدی پشتیبانی‌شده‌ای نمی‌یابد که آن را ترجمه کند. بسته به جدول‌ها، در مرز خروج حذف می‌شود، و چون تونل UP می‌ماند و نمونه‌ای در همان subnet به اینترنت می‌رسد، خطا به‌عنوان مشکل firewall در سایت محلی گزارش می‌شود.

virtual private gateway در برابر transit gateway

virtual private gateway به یک VPC تعلق دارد. VPN را پایان می‌دهد، مسیرها را در جدول‌های آن VPC نصب می‌کند و همان‌جا می‌ایستد. مدل attachment ندارد، پس نمی‌تواند ترافیک را به VPC دیگر یا به بخش خروج مشترک بدهد. همین دامنه تک‌VPC تمام محدودیت است و هیچ مسیری که داخل VPC اضافه کنید آن را تغییر نمی‌دهد.

transit gateway یک هاب منطقه‌ای است که VPN، هر spoke VPC و یک VPC خدمات مشترک در آن به‌صورت attachment ظاهر می‌شوند. جدول‌های مسیر خودش را دارد که انتخاب می‌کنند کدام attachment یک prefix معین را دریافت کند.

همین هاب خروج متمرکز را ممکن می‌کند: VPN به‌عنوان یک attachment فرود می‌آید، VPC خروج به‌عنوان دیگری، و جدول مسیر transit gateway prefixهای رو به اینترنت را از اولی به دومی می‌فرستد. با virtual private gateway attachment دومی برای فرستادن چیزی وجود ندارد، از این رو طراحی بعداً وصله‌پذیر نیست.

مسیر خروج پشتیبانی‌شده، گام به گام

طراحی مرجع پنج گام دارد و هر پیکان یک تصمیم مسیریابی است که باید پیکربندی کنید. ترافیک از شبکه محلی به attachment مربوط به Site-to-Site VPN خارج می‌شود، جدول transit gateway آن را به attachment مربوط به VPC خروج می‌فرستد، و در آنجا جدول subnet آن را به یک NAT gateway عمومی می‌فرستد. NAT gateway مبدأ را ترجمه می‌کند و internet gateway بسته را بیرون می‌برد.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

دو جزئیات تعیین می‌کند آیا گام‌های آخر کار می‌کنند. NAT gateway باید عمومی باشد، با elastic IP و مسیری به internet gateway، زیرا NAT gateway خصوصی بین شبکه‌ها ترجمه می‌کند و هرگز خروجی اینترنت نمی‌شود.

برای هر Availability Zone که می‌خواهید سرویس دهید یک NAT gateway برنامه‌ریزی کنید و هر جدول subnet به نمونه محلی اشاره کند. جدول transit gateway و جدول‌های VPC را در یادداشت‌هایتان اشیای جدا نگه دارید، چون یکی attachment و دیگری منبعی داخل VPC را انتخاب می‌کند. مسیر پیش‌فرض فقط در یکی از آن‌ها نیمی از مسیر را تعریف‌نشده می‌گذارد و همان خطاهای جزئی را می‌سازد که سخت‌ترین انتساب را دارند.

مسیر بازگشت جایی است که این طراحی‌ها شکست می‌خورند

NAT gateway برای جریان‌هایی که دیده است حالت نگه می‌دارد، پس پاسخ‌های یک اتصال خروجی بدون قاعده ورودی تازه برمی‌گردند. این ویژگی یک سرویس محلی را در اینترنت منتشر نمی‌کند، و رفتار کردن با آن به‌عنوان چنین چیزی باعث می‌شود تیم یک روز را صرف اشکال‌زدایی اتصالی کند که هرگز برقرار نمی‌شد. برای ترافیک آغازشده از سمت کلاینت چهار مسیر باید توافق کنند: سیاست سایت محلی، جدول transit gateway، جدول subnet خروج و جدول subnet مربوط به NAT. اگر آخری جا بیفتد، درخواست ساختمان را ترک می‌کند در حالی که پاسخ داخل AWS می‌میرد.

با یک کلاینت واقعی پشت VPN اعتبارسنجی کنید و ببینید چه نشانی مبدأ عمومی ارائه می‌دهد. اگر elastic IP مربوط به NAT gateway است، ترجمه انجام می‌شود؛ اگر چیز دیگری است، خروج دیگری را می‌سنجید.

نسخه نامتقارن این خطا ارزش شناخت زودهنگام را دارد. وقتی جدول subnet مربوط به NAT در یک Availability Zone مسیر بازگشت به prefix کلاینت را دارد و دیگری ندارد، اتصال‌های تازه بسته به منطقه‌ای که جریان در آن می‌افتد موفق یا ناموفق می‌شوند و این الگو به‌اشتباه اینترنت بی‌ثبات خوانده می‌شود. جدول‌های subnet را برای هر منطقه‌ای که سرویس می‌دهید مقایسه کنید، نه اینکه همان منطقه‌ای را که تیکت در آن باز شده درست کنید، چون مسیر گم‌شده خودِ تمام عیب است و در سمت دیگر چیزی نیاز به تغییر ندارد.

چه زمانی proxy صریح طراحی بهتری است

یک HTTP proxy روی نمونه‌ای در VPC خروج جایگزین مشروعی است و اغلب ارزان‌تر. کلاینت‌ها برای استفاده از آن پیکربندی می‌شوند، proxy اتصال خودش را به بیرون باز می‌کند و مسیر بازگشت مشکل اوست نه معمای مسیریابی متقارن. برای تعداد کمی برنامه این بخش عمده کار transit gateway را حذف می‌کند. همچنین گزارش‌گیری به‌ازای هر کاربر می‌دهد که NAT gateway نمی‌تواند تولید کند.

اما شفاف نیست. هر چیزی که تنظیمات proxy را نادیده بگیرد، و هر پروتکلی که HTTP نباشد، این مسیر را دنبال نخواهد کرد.

انتخاب به این بستگی دارد که برنامه‌های شما واقعاً چه زبانی صحبت می‌کنند و چه مقدار هویت در گزارش‌ها لازم دارید. جایی که HTTP صحبت می‌کنند، proxy جای خود را می‌گیرد؛ جایی که خروج عمومی برای پروتکل‌های دلخواه لازم دارید، طراحی با transit gateway همان است که AWS پشتیبانی می‌کند. تصمیم زودهنگام ارزان‌تر از کشف آن پس از ساخت جدول‌های مسیر است.