افزودن یک زیرشبکه محلی به AWS VPN: VGW در برابر Transit Gateway

یک VPN موجود از نوع Site-to-Site نشانی 10.60.0.0/16 را حمل می‌کند، یک شبکه سرویس جدید پشت همان دروازه محلی با نشانی 10.70.0.0/16 ظاهر می‌شود و کسی می‌پرسد آیا پروکسی لازم است. معمولاً نه: مسیر مسیریابی‌شده می‌تواند پیشوند را حمل کند، اما تنها اگر سه چیز هم‌زمان جور شوند، و اینکه کدام سه، به معماری AWS بستگی دارد که از قبل اجرا می‌کنید. یک دروازه خصوصی مجازی یک مرز جدول مسیریابی دارد؛ یک transit gateway مرز دومی اضافه می‌کند. درست بودن اعلام و غلط بودن جدول، نشستی می‌سازد که سالم به نظر می‌رسد و چیزی تحویل نمی‌دهد.

پیشوندی منتشر کنید که دروازه واقعاً بتواند تحویل دهد

دروازه محلی پیش از آنکه هر اعلامی معنا داشته باشد، به یک مسیر رو به جلو به شبکه جدید نیاز دارد. اعلام 10.70.0.0/16 از طریق BGP به AWS می‌گوید بسته‌های آن محدوده را کجا بفرستد؛ اما مسیر ارسال محلی را که محدوده را در طرف دیگر قابل دسترسی می‌کند ایجاد نمی‌کند. تأیید کنید که دروازه برای پیشوند مسیری دارد که به دستگاهی که آن را نگه می‌دارد اشاره می‌کند و دستگاه برای پاسخ دادن به آن نشانی‌ها پیکربندی شده است. سیاست خروجی و محدودیت‌های پیشوند پذیرفته‌شده قید بعدی هستند، زیرا پیشوندی که نشست آن را فیلتر می‌کند هرگز به AWS نمی‌رسد.

تجمیع‌ها و مسیرهای مشخص‌تر را آگاهانه نگه دارید. مسیرهای هم‌پوشانی که از دو جهت می‌آیند یک تصمیم طراحی‌اند، نه جزئیاتی که بعداً کشف شود.

مسیر یک: مرز دروازه خصوصی مجازی

با یک دروازه خصوصی مجازی، مستندات مسیریابی AWS VPN دو حالت توزیع را توصیف می‌کند: مسیرهای ایستا و اعلام‌های BGP، و هر دو به جدول مسیریابی زیرشبکه‌ای بستگی دارند که برنامه واقعاً از آن استفاده می‌کند. انتشار وقتی کل محدوده را کنترل می‌کنید راحت است، و مسیر صریح وقتی می‌خواهید مقصد کنار هدف فهرست شود راحت‌تر استدلال می‌شود. در هر حال بررسی یکی است: آیا جدول زیرشبکه مشخص برنامه مسیر کاری به هدف VPN برای پیشوند جدید دارد، و آیا در برابر چیزی مشخص‌تر پیروز می‌شود؟

نشست BGP سالم ثابت می‌کند کانال وجود دارد. درباره اینکه جدول زیرشبکه معینی مسیر را مصرف کرده یا نه چیزی نمی‌گوید.

مسیر دو: transit gateway یک جدول اضافه می‌کند

یک transit gateway آن پرسش واحد را به دو بخش تقسیم می‌کند. زیرشبکه VPC باید مقصد را به اتصال transit gateway بفرستد و سپس جدول مسیریابی transit gateway باید اتصال VPN را برای همان پیشوند انتخاب کند. انتخاب‌های انجمن و انتشار تعیین می‌کنند کدام شبکه‌های متصل مسیر را دریافت کنند، بنابراین یک پیشوند می‌تواند به‌درستی توسط VPN اعلام شود و باز هم هرگز به VPCی نرسد که جدولش هرگز با جدول مسیریابی درست مرتبط نشده است.

شکست رایج این است: مسیری که در یک جدول هست و در جدول دیگر نیست، و هر تیمی مطمئن است که سمت خودش درست است. وقتی دو معماری را مقایسه می‌کنید، همین مرز اضافه تمام تفاوت است: جاهای بیشتری برای نگاه کردن و کنترل دقیق‌تر بر اینکه چه کسی مسیر را دریافت می‌کند.

انتشار مسیر هم به هر اتصالی پیشوند را نمی‌دهد. آن را به جدول‌هایی توزیع می‌کند که برای دریافتش پیکربندی شده‌اند.

مسیر بازگشت تصمیم سیاستی مستقل خودش است

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

هم‌پوشانی نشانی‌ها تله دیگر است. محدوده‌های جدا و با مالکیت صریح این را ساده نگه می‌دارند؛ محدوده‌های هم‌پوشان به معنای ترجمه یا بازطراحی است و هیچ‌یک گونه‌ای قابل تبادل از همان دستورالعمل نیست.

با مبدأیی در شبکه جدید و مقصدی در زیرشبکه برنامه آزمایش کنید، سپس در جهت دیگر تکرار کنید. آزمون یک‌طرفه تنها یک جهت را اثبات می‌کند.

چه زمانی پروکسی واقعاً مرز بهتر است

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

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