AWS Site-to-Site VPN кон NAT Gateway: VGW наспроти Transit Gateway

Сите првиот пат го цртаат истиот дијаграм: VPN во VPC, NAT gateway кон интернет, готово. Но AWS не ја поддржува таа патека кога VPN завршува на virtual private gateway, а грешката е толку тивка што тимовите ја преградуваат повеќе од еднаш. Работечкиот дизајн бара transit gateway, што ги менува gateway-от и табелите со рути од двете страни. Споредете ги двете форми пред да нацртате нешто.

Топологијата што изгледа очигледна и не е поддржана

Документацијата за NAT gateway на AWS повлекува линија што го изненадува секој што градел само дизајни со еден VPC: сообраќајот од Site-to-Site VPN врска не може да се насочи кон NAT gateway преку virtual private gateway. Типот на gateway на кој завршува VPN-от одлучува дали воопшто постои патека за превод. Грешката опстојува затоа што статусот на тунелот е UP и EC2 инстанца во истиот subnet стигнува до интернет без проблем. Ниту едно од двете набљудувања не го проверува расипаниот правец.

Во пракса пакетот пристигнува со изворна адреса од локалната мрежа и не наоѓа поддржан следен хоп што би го превел. Според табелите се отфрла на излезната граница, а бидејќи тунелот останува UP додека инстанца во истиот subnet стигнува до интернет, грешката се пријавува како проблем со firewall на локалната страна.

Virtual private gateway наспроти transit gateway

Virtual private gateway припаѓа на еден VPC. Тој го завршува VPN-от, инсталира рути во табелите на тој VPC и застанува таму. Нема модел на attachment, па не може да предаде сообраќај на друг VPC или на заеднички излезен сегмент. Целиот опсег на еден VPC е ограничувањето и ниту една рута додадена внатре во VPC не го менува тоа.

Transit gateway е регионален центар каде VPN-от, секој spoke VPC и VPC за заеднички услуги се појавуваат како attachment. Има сопствени табели со рути што избираат кој attachment добива даден prefix.

Тој центар ја овозможува централизираната излезна точка: VPN-от слетува како еден attachment, излезниот VPC како друг, а табелата на transit gateway ги праќа prefix-ите кон интернет од првиот кон вториот. Со virtual private gateway нема втор attachment каде да се прати нешто, затоа дизајнот не може да се закрпи подоцна.

Поддржаната излезна патека, хоп по хоп

Референтниот дизајн има пет хопа и секоја стрелка е одлука за рутирање што треба да ја конфигурирате. Сообраќајот излегува од локалната мрежа во Site-to-Site VPN attachment, табелата на transit gateway го препраќа кон излезниот VPC attachment, каде табелата на subnet го праќа кон јавниот NAT gateway. NAT gateway го преведува изворот, а internet gateway го изнесува пакетот.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Два детали одлучуваат дали последните хопови работат. NAT gateway мора да биде јавен, со elastic IP и рута кон internet gateway, бидејќи приватен NAT gateway преведува меѓу мрежи и никогаш не станува излез кон интернет.

Планирајте еден NAT gateway на секој Availability Zone што сакате да го опслужувате, а секоја табела на subnet нека покажува кон локалниот. Држете ја табелата на transit gateway и табелите на VPC како одделни објекти во белешките, бидејќи едната избира attachment, а другата ресурс внатре во VPC. Стандардна рута само во едната од двете го остава половина пат неодреден и создава делумни дефекти што најтешко се припишуваат.

Токму на повратната патека овие дизајни паѓаат

NAT gateway чува состојба за текови што веќе ги видел, па одговорите на излезна врска се враќаат без ново влезно правило. Тоа својство не објавува локална услуга на интернет, и однесувањето како да објавува чини тим еден ден за дебагирање врска што никогаш немаше да се воспостави. За сообраќај што го започнува клиентот, четири рути мора да се согласат: локалната политика, табелата на transit gateway, излезната subnet табела и NAT subnet табелата. Ако ја пропуштите последната, барањето ја напушта зградата додека одговорот умира внатре во AWS.

Проверете со вистински клиент зад VPN-от и погледнете која јавна изворна адреса ја прикажува. Ако е elastic IP на NAT gateway, преводот се случува; ако е нешто друго, мерите друг излез.

Асиметричната верзија на овој дефект вреди да се препознае рано. Кога NAT subnet табелата на еден Availability Zone ја има повратната рута кон prefix-от на клиентот, а друг не, новите врски успеваат или паѓаат зависно од зоната во која слетува текот, и шемата погрешно се чита како нестабилен интернет. Споредете ги subnet табелите за секоја зона што ја опслужувате наместо да ја поправате онаа каде е отворен тикетот, бидејќи рутата што недостига е целиот дефект и од другата страна ништо не треба да се менува.

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

HTTP proxy на инстанца во излезниот VPC е легитимна алтернатива и често поевтина. Клиентите се конфигурираат да го користат, proxy-то отвора своја врска кон надвор, а повратната патека станува негов проблем наместо загатка со симетрично рутирање. За мал број апликации тоа го отстранува поголемиот дел од работата со transit gateway. Дава и логирање по корисник што NAT gateway не може да го произведе.

Но не е транспарентен. Сè што ги игнорира поставките на proxy и секој протокол што не е HTTP нема да ја следат таа патека.

Изборот зависи од тоа што навистина зборуваат вашите апликации и колку идентитет ви треба во логовите. Каде што зборуваат HTTP, proxy-то го заслужува местото; каде што треба општ излез за произволни протоколи, дизајнот со transit gateway е оној што AWS го поддржува. Да се одлучи тоа однапред е поевтино отколку да се открие откако табелите со рути се изградени.