Один VPN між майданчиками для кількох VPC у AWS Transit Gateway

Підключіть VPN один раз, а кожен VPC — до одного транзитного шлюзу, потім розділіть зв'язування й поширення, щоб філії бачили офіс, але не одна одну.

Двом VPC цього кварталу потрібна офісна мережа, і саме на другому тунелі оцінка ламається. AWS Transit Gateway може служити спільним маршрутизувальним центром: VPN підключається один раз, і кожен VPC підключається до того самого центру. Далі локальна мережа досягає кожного підключеного VPC через одне з'єднання. Це змінює, кому належить рішення про маршрутизацію, і саме цю частину більшість проєктів роблять неправильно.

Приєднання VPN і приєднання VPC — різні об'єкти на одному шлюзі, тому зв'язки маршрутизації доводиться будувати пізніше.

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

Чому peering — не той короткий шлях, на який сподіваються

Спокуслива альтернатива — завершити VPN на VPC A і з'єднати VPC B з ним через peering. Звичайний VPC peering не дає транзиту від краю до краю через VPN-з'єднання A. Партнер досягає лише адрес, які надає сам peering, а VPN-край до них не належить. Транзит дає центр; peering дає пару.

Це обмеження — властивість peering, а не квота, яку можна підняти.

Зв'язування й поширення виконують різну роботу

Усередині транзитного шлюзу зв'язування вибирає таблицю маршрутів, за якою шукається трафік, що надходить від приєднання. Поширення вирішує, які таблиці отримають вивчені або підключені префікси приєднання. Одне приєднання може бути зв'язане з однією таблицею й водночас поширюватися в кілька. Плутанина між цими двома поняттями — шлях до досяжності, яку ніхто не планував.

Повністю зв'язаний малий центр — простий випадок.

Помістіть кожне приєднання в одну таблицю, і VPN разом з обома префіксами VPC вирішується чисто. Це також дозволяє досяжність між VPC, якої організація, можливо, ніколи не задумувала, бо спільна таблиця не знає поняття філії.

Маршрути робочих навантажень живуть в іншому місці

Кожній підмережі робочого навантаження все ще потрібен власний маршрут до транзитного шлюзу для потрібних локальних префіксів. Ті таблиці маршрутів VPC — окремі об'єкти від власних таблиць транзитного шлюзу. Додайте потрібні префікси й збережіть наявні маршрути замість заміни кожного призначення новим default. Маршрут підмережі також нічого не оголошує пристрою клієнта.

Обирайте динамічну чи статичну маршрутизацію свідомо; peering не дає жодної.

Ізолюйте філії, не втрачаючи локальний доступ

Коли A і B обидва можуть досягати офісу, але не повинні маршрутизуватися одне до одного, розділіть таблиці. Зв'язана таблиця приєднання VPN містить префікси VPC. Зв'язана таблиця приєднань VPC містить локальні префікси, без маршруту, що з'єднує A з B. Саме поширення створює цей зв'язок, тож приймати кожне стандартне зв'язування не доводиться.

Це ізоляція маршрутизації, а не авторизація застосунку.

Групи безпеки, мережеві ACL, брандмауери хостів і власні дозволи кожної служби все ще вирішують, який трафік допускається. Якщо потрібна інспекція, проєктуйте її підтримуваний шлях явно, а не припускайте, що центр її виконує.

Чого центр не виправляє

Плани адрес усе ще не повинні перетинатися, бо центр не дозволяє одному префіксу позначати два робочі навантаження. Кожному приєднанню VPC потрібне покриття Availability Zone, якого очікують його робочі навантаження. З BGP маршрути пристрою клієнта назад до кожного потрібного префікса мають відповідати проєкту та його політиці імпорту. Відсутнє оголошення виглядає точно як зламаний тунель.

VPN-з'єднання й транзитний шлюз тепер спільна інфраструктура.

Плануйте резервування тунелів, ємність пристроїв, моніторинг і обслуговування навколо всіх залежних VPC, а не розглядайте кожен як незалежно підключений.

Перехід із наявної схеми virtual private gateway заслуговує такого самого явного плану. Побудуйте приєднання й політики, перенесіть один контрольований шлях робочого навантаження та підтвердьте дозволені й заборонені зв'язки, перш ніж виводити старий шлях. Централізація допомагає, коли дає мережевій команді одне місце для керування спільною зв'язністю, і шкодить, коли ховає, хто кого може досягти, за однією великою таблицею.

Схожі статті