Један 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

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