یک VPN نقطه‌به‌نقطه برای چند VPC روی AWS Transit Gateway

دو VPC این فصل به شبکه دفتر نیاز دارند و همان‌جا در تونل دوم است که برآورد می‌شکند. AWS Transit Gateway می‌تواند نقش یک مرکز مسیریابی مشترک را بازی کند: VPN یک بار متصل می‌شود و هر VPC به همان مرکز متصل می‌شود. سپس شبکه محلی از طریق یک اتصال به هر VPC متصل می‌رسد. این تغییر می‌دهد که تصمیم مسیریابی در اختیار چه کسی است و بیشتر طرح‌ها دقیقاً همین بخش را اشتباه می‌کنند.

اتصال VPN و اتصال‌های VPC اشیای جداگانه‌ای روی همان دروازه هستند، به همین دلیل روابط مسیریابی باید بعداً ساخته شوند.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

چرا همتابندی آن میان‌بری نیست که مردم امیدش را دارند

گزینه وسوسه‌انگیز این است که VPN را روی VPC A پایان دهید و VPC B را با آن همتابند کنید. همتابندی معمول VPC عبور سرتاسری از طریق اتصال VPN مربوط به A فراهم نمی‌کند. همتا فقط به نشانی‌هایی می‌رسد که خود همتابندی فراهم می‌کند و لبه VPN یکی از آن‌ها نیست. عبور چیزی است که یک مرکز می‌دهد؛ همتابندی به شما یک جفت می‌دهد.

این محدودیت ویژگی همتابندی است، نه سهمیه‌ای که بتوانید بالا ببرید.

ارتباط و انتشار کارهای متفاوتی انجام می‌دهند

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

مرکز کوچک کاملاً متصل حالت آسان است.

هر اتصال را در یک جدول بگذارید تا VPN همراه با هر دو پیشوند VPC به‌درستی حل شود. این کار دسترس‌پذیری بین VPC را هم ممکن می‌کند که سازمان شاید هرگز نمی‌خواست، چون یک جدول مشترک مفهومی از شاخه ندارد.

مسیرهای بارهای کاری جای دیگری زندگی می‌کنند

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

مسیریابی پویا یا ایستا را آگاهانه انتخاب کنید؛ همتابندی هیچ‌کدام را فراهم نمی‌کند.

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

وقتی A و B هر دو می‌توانند به دفتر برسند اما نباید به سمت یکدیگر مسیریابی کنند، جدول‌ها را تقسیم کنید. جدول مرتبط اتصال VPN پیشوندهای VPC را نگه می‌دارد. جدول مرتبط اتصال‌های VPC پیشوندهای محلی را نگه می‌دارد، بدون مسیری که A را به B پیوند دهد. انتشار همان رابطه را می‌سازد، پس هرگز لازم نیست همه ارتباط‌های پیش‌فرض را بپذیرید.

این جداسازی مسیریابی است و مجوزدهی سطح برنامه نیست.

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

چیزی که مرکز درستش نمی‌کند

طرح‌های نشانی باید همچنان بدون هم‌پوشانی باشند، چون مرکز اجازه نمی‌دهد یک پیشوند دو بار کاری را مشخص کند. هر اتصال VPC به پوشش Availability Zone که بارهای کاری‌اش انتظار دارند نیاز دارد. با BGP، مسیرهای دستگاه مشتری به هر پیشوند لازم باید با طرح و سیاست ورود آن مطابقت داشته باشد. اعلامی که جا افتاده دقیقاً مثل تونلی شکسته به نظر می‌رسد.

اتصال VPN و دروازه گذر اکنون زیرساخت مشترک هستند.

افزونگی تونل‌ها، ظرفیت دستگاه‌ها، پایش و نگهداری را حول همه VPCهای وابسته برنامه‌ریزی کنید، نه اینکه هر یک را مستقل متصل‌شده در نظر بگیرید.

مهاجرت از یک چیدمان virtual private gateway موجود همان طرح صریح را می‌طلبد. اتصال‌ها و سیاست‌ها را بسازید، یک مسیر بار کاری کنترل‌شده را جابه‌جا کنید و پیش از بازنشسته کردن مسیر قدیمی، روابط مجاز و ردشده را تأیید کنید. تمرکز زمانی کمک می‌کند که به تیم شبکه یک نقطه برای مدیریت اتصال مشترک بدهد و زمانی آسیب می‌زند که پشت یک جدول بزرگ پنهان کند چه کسی اجازه دارد به چه کسی برسد.