Додавање локална подмрежа на AWS VPN: VGW или Transit Gateway
BGP објавата му кажува на AWS каде да праќа пакети; таа не создава локална патека. Проверете ја границата на 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 преку правилната порта, а безбедносната политика на двата краја мора да го дозволи тој пар извор и одредиште. Ако тунелот преговара за заштитен опсег со селектори на сообраќај, новиот префикс мора да биде внатре во него, инаку пакетот се отфрла пред да се погледне која било табела за рутирање.
Преклопувањето на адреси е другата стапица. Одделни, јасно сопствени опсези го држат ова едноставно; опсезите што се преклопуваат значат превод или редизајн, и ниту едното не е заменлива варијанта на истиот рецепт.
Тестирајте со извор во новата мрежа и одредиште во апликациската подмрежа, потоа повторете во спротивниот правец. Еднонасочно тестирање докажува само еден правец.
Кога проксито навистина е подобра граница
Проксито го заслужува своето место кога барањето е тесен сервисен интерфејс, кога апликацијата веќе ја очекува таа архитектура или кога мрежната патека не може да се натера да го пренесува префиксот без превод што не го сакате. Тоа не е резервно решение за запис во табелата за рутирање што никој не го проверил.
Одлучете по овој ред: локално проследување, објава, граница на табелата, политика за враќање. Поправете го првото што ќе падне и само потоа прашајте дали рутираната патека воопшто е точниот одговор.