Додавање локалне подмреже на AWS VPN: VGW наспрам Transit Gateway

Постојећи Site-to-Site VPN преноси 10.60.0.0/16, иза истог локалног gateway-а појављује се нова сервисна мрежа као 10.70.0.0/16, и неко пита да ли је потребан прокси. Обично није: рутирана путања може да пренесе префикс, али само ако се поклопе три ствари, а које три зависи од AWS архитектуре коју већ водите. Виртуелни приватни gateway има једну границу табеле рута; transit gateway додаје другу. Исправан оглас уз погрешну табелу даје сесију која изгледа здраво и не доставља ништа.

Објавите префикс који gateway заиста може да достави

Локалном gateway-у је потребна рута ка новој мрежи пре него што било који оглас има смисла. Оглашавање 10.70.0.0/16 кроз BGP говори AWS-у где да шаље пакете за тај опсег; оно не ствара локалну путању прослеђивања која опсег чини доступним на другом крају. Потврдите да gateway има руту за префикс која показује на уређај који га држи и да је уређај конфигурисан да одговара на те адресе. Политика извоза и прихваћени лимити префикса су следеће ограничење, јер префикс који сесија филтрира никада не стиже до AWS-а.

Нека агрегати и специфичније руте буду намерни. Путање које се преклапају и долазе из два смера су дизајнерска одлука, а не детаљ који се открива касније.

Путања прва: граница виртуелног приватног gateway-а

Уз виртуелни приватни gateway, AWS VPN документација за рутирање описује два начина дистрибуције — статичне руте и BGP огласе — а оба зависе од табеле рута подмреже коју апликација заиста користи. Пропагација је згодна када контролишете цео опсег, а експлицитна рута се лакше промишља када желите одредиште наведено уз циљ. У оба случаја провера је иста: садржи ли табела конкретне апликационе подмреже радну путању до VPN циља за нови префикс и побеђује ли против нечег специфичнијег?

Здрава BGP сесија доказује да канал постоји. Не говори ништа о томе да ли је одређена табела подмреже преузела руту.

Путања друга: transit gateway додаје табелу

Transit gateway дели то једно питање на два. VPC подмрежа мора да пошаље одредиште на прикључак transit gateway-а, а затим табела рута transit gateway-а мора да изабере VPN прикључак за исти префикс. Избори асоцијације и пропагације одлучују које прикључене мреже добијају руту, па префикс може бити исправно оглашен кроз VPN и ипак никада не стигне до VPC-а чија табела никада није била повезана са правом табелом рута.

Уобичајени квар је рута која постоји у једној табели, а не у другој, при чему је сваки тим уверен да је његова страна исправна. Када упоредите две архитектуре, та додатна граница је цела разлика: више места за проверу и прецизнија контрола над тим ко добија руту.

Пропагација рута такође не даје префикс сваком прикључку. Она га дистрибуира табелама конфигурисаним да га примају.

Повратна путања је засебна политичка одлука

Саобраћај који стигне само је половина размене. Нова локална мрежа треба руту назад ка AWS изворним префиксима кроз исправан gateway, а безбедносна политика на оба краја мора да дозволи тај пар извора и одредишта. Ако тунел преговара обим заштите са селекторима саобраћаја, нови префикс мора бити унутар њега, иначе се пакет одбацује пре него што се погледа било која табела рута.

Преклапање адреса је друга замка. Непреклапајући, изричито поседовани опсези држе ово једноставним; опсези који се преклапају значе превођење или редизајн, а ниједно није заменљива варијанта истог рецепта.

Тестирајте са извором у новој мрежи и одредиштем у апликационој подмрежи, па поновите у супротном смеру. Једносмерни тест доказује само један смер.

Када је прокси заиста боља граница

Прокси заслужује своје место када је захтев узак сервисни интерфејс, када апликација већ очекује ту архитектуру или када се мрежна путања не може натерати да преноси префикс без превођења које не желите. Он није резервно решење за унос у табели рута који нико није проверио.

Одлучите овим редом: локално прослеђивање, оглас, граница табеле, политика повратка. Поправите прво које падне и тек онда питајте да ли је рутирана путања уопште прави одговор.