Еден 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 и да го peering-поврзете VPC B со него. Обичниот 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 заслужува истиот експлицитен план. Изградете ги приклучоците и политиките, преместете една контролирана патека на работно оптоварување и потврдете ги дозволените и одбиените односи пред да ја повлечете старата патека. Централизацијата помага кога на мрежниот тим му дава едно место да управува заедничка поврзаност, а штети кога крие кој со кого може да стигне зад една голема табела.

Поврзани статии