AWS Site-to-Site VPN ка NAT Gateway-у: VGW наспрам Transit Gateway-а

Сви први пут цртају исту шему: VPN у VPC, NAT gateway напоље ка интернету, готово. Али AWS не подржава тај пут када VPN завршава на virtual private gateway, а грешка је довољно тиха да је тимови поново граде више од једном. Исправан дизајн захтева transit gateway, што мења gateway и табеле рута на обе стране. Упоредите два облика пре него што било шта нацртате.

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

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

У пракси пакет долази са изворном адресом из локалне мреже и не налази подржан следећи хоп који би га превео. У зависности од табела, одбацује се на излазној граници, а пошто тунел остаје UP док инстанца у истој подмрежи достиже интернет, квар се пријављује као проблем локалног firewall-а.

Virtual private gateway наспрам transit gateway-а

Virtual private gateway припада једном VPC-у. Он завршава VPN, уписује руте у табеле тог VPC-а и ту се зауставља. Нема модел прикључка, па не може да преда трафик другом VPC-у ни заједничком излазном сегменту. Тај обухват једног VPC-а је цело ограничење и ниједна рута додата унутар VPC-а то не мења.

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

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

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

Референтни дизајн има пет хопова и свака стрелица је одлука о усмеравању коју морате да подесите. Трафик излази из локалне мреже у Site-to-Site VPN прикључак, табела рута transit gateway-а прослеђује га излазном VPC прикључку, где га табела подмреже шаље на јавни 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 коју намеравате да опслужујете, а свака табела подмреже нека показује на локални. Држите табелу transit gateway-а и табеле VPC-а као одвојене објекте у белешкама, јер једна бира прикључак, а друга ресурс унутар VPC-а. Подразумевана рута само у једној од њих оставља половину пута неодређеном и ствара делимичне кварове које је најтеже приписати.

Управо на повратном путу ови дизајни падају

NAT gateway памти стање за токове које је већ видео, па се одговори на одлазну везу враћају без новог улазног правила. То својство не објављује локалну услугу на интернету, а понашање као да објављује кошта тим даном отклањања грешака на вези која се никада не би успоставила. За саобраћај који започиње клијент морају се сложити четири руте: локална политика, табела transit gateway-а, излазна табела подмреже и NAT табела подмреже. Промашите ли последњу, захтев напушта зграду док одговор умире унутар AWS-а.

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

Асиметричну верзију ове грешке вредно је препознати рано. Када NAT табела подмреже једне Availability Zone има повратну руту на префикс клијента, а друга нема, нове везе успевају или падају у зависности од зоне у коју ток слети, а образац се погрешно чита као нестабилан интернет. Упоредите табеле подмрежа за сваку зону коју опслужујете уместо да поправљате ону у којој је отворен тикет, јер рута која недостаје је цео квар и на другој страни ништа не треба мењати.

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

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

Није, међутим, транспарентан. Све што игнорише proxy подешавања и сваки протокол који није HTTP неће ићи тим путем.

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