Добавяне на локална подмрежа към AWS VPN: VGW срещу Transit Gateway

Съществуващ Site-to-Site VPN пренася 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 през правилния шлюз, а политиката за сигурност от двете страни трябва да разрешава тази двойка източник и дестинация. Ако тунелът договаря обхват на защита със селектори на трафик, новият префикс трябва да е в него, иначе пакетът се изхвърля, преди да бъде прегледана каквато и да е таблица за маршрутизиране.

Припокриването на адреси е другата капана. Непресичащите се, изрично притежавани диапазони държат това просто; припокриващите се диапазони означават транслация или препроектиране и нито едно от двете не е взаимозаменяем вариант на същата рецепта.

Тествайте с източник в новата мрежа и дестинация в приложната подмрежа, после повторете в обратната посока. Еднопосочният тест доказва една посока.

Когато проксито наистина е по-добрата граница

Проксито заслужава мястото си, когато изискването е тесен сервизен интерфейс, когато приложението вече очаква такава архитектура или когато мрежовият път не може да пренесе префикса без транслация, която не искате. То не е резервният вариант за запис в таблица за маршрутизиране, който никой не е проверил.

Решавайте в този ред: локално препращане, анонс, граница на таблицата, политика за връщане. Поправете първото, което се провали, и едва после питайте дали маршрутизираният път изобщо е правилният отговор.