AWS Site-to-Site VPN patungong NAT Gateway: VGW kumpara sa Transit Gateway

Iginuguhit ng lahat ang parehong diagram sa unang pagkakataon: VPN papasok sa VPC, NAT gateway palabas sa internet, tapos. Ngunit hindi sinusuportahan ng AWS ang rutang iyon kapag nagtatapos ang VPN sa virtual private gateway, at sapat na tahimik ang pagkabigo para muling itayo ito ng mga koponan nang higit sa isang beses. Ang disenyong gumagana ay nangangailangan ng transit gateway, na nagbabago sa gateway at mga talaan ng ruta sa magkabilang panig. Ihambing ang dalawang hugis bago gumuhit ng anuman.

Ang topology na mukhang malinaw at hindi sinusuportahan

Ang dokumentasyon ng NAT gateway ng AWS ay gumuhit ng linyang ikinagulat ng sinumang nakagawa lamang ng mga disenyong may isang VPC: hindi maaaring iruta ang trapiko mula sa koneksyong Site-to-Site VPN patungo sa NAT gateway sa pamamagitan ng virtual private gateway. Ang uri ng gateway kung saan nagtatapos ang VPN ang nagpapasya kung may rutang pagsasalin man. Nabubuhay ang pagkakamali dahil UP ang estado ng tunnel at ang instans ng EC2 sa parehong subnet ay umaabot sa internet nang walang problema. Wala sa dalawang obserbasyong iyon ang sumusubok sa sirang direksyon.

Sa pagsasagawa, dumarating ang packet na may pinagmulang address mula sa lokal na network at walang makitang sinusuportahang susunod na hop na magsasalin nito. Depende sa mga talaan, itinatapon ito sa hangganan ng labasan, at dahil nananatiling UP ang tunnel habang ang instans sa parehong subnet ay umaabot sa internet, iniuulat ang pagkabigo bilang problema sa firewall sa lokal na panig.

Virtual private gateway kumpara sa transit gateway

Ang isang virtual private gateway ay pag-aari ng isang VPC. Tinatapos nito ang VPN, naglalagay ng mga ruta sa mga talaan ng rutang iyon, at humihinto doon. Wala itong modelong attachment, kaya hindi nito maipapasa ang trapiko sa ibang VPC o sa pinagsamang segment ng labasan. Ang saklaw na isang VPC ang buong limitasyon, at walang rutang idaragdag mo sa loob ng VPC ang makakabago nito.

Ang transit gateway ay isang rehiyonal na hub kung saan lumilitaw ang VPN, bawat spoke VPC at isang VPC ng pinagsamang serbisyo bilang mga attachment. May sarili itong mga talaan ng ruta na pumipili kung aling attachment ang tatanggap ng isang prefix.

Ang hub na iyon ang nagpapangyari sa sentralisadong labasan: dumarating ang VPN bilang isang attachment, ang labasang VPC bilang isa pa, at ang talaan ng ruta ng transit gateway ay nagpapadala ng mga prefix patungong internet mula sa una hanggang sa pangalawa. Sa virtual private gateway, walang pangalawang attachment na mapapadalhan, kaya hindi maaaring tagpian ang disenyo mamaya.

Ang sinusuportahang rutang labasan, hop bawat hop

May limang hop ang sangguniang disenyo at bawat palaso ay desisyon sa pagruruta na kailangan mong isaayos. Lumalabas ang trapiko mula sa lokal na network patungo sa attachment ng Site-to-Site VPN, ipinapasa ito ng talaan ng transit gateway sa attachment ng labasang VPC, kung saan ipinapadala ito ng talaan ng subnet sa pampublikong NAT gateway. Isinasalin ng NAT gateway ang pinagmulan at inilalabas ng internet gateway ang packet.

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

Dalawang detalye ang nagpapasya kung gagana ang huling mga hop. Dapat pampubliko ang NAT gateway, may elastic IP at rutang patungo sa internet gateway, dahil ang pribadong NAT gateway ay nagsasalin sa pagitan ng mga network at hindi kailanman nagiging labasan sa internet.

Magplano ng isang NAT gateway bawat Availability Zone na nais mong pagsilbihan, at bawat talaan ng subnet ay tumuturo sa lokal. Itago ang talaan ng transit gateway at ang mga talaan ng VPC bilang magkahiwalay na bagay sa iyong mga tala, dahil ang isa ay pumipili ng attachment at ang isa ay pumipili ng resource sa loob ng VPC. Ang default route sa isa lamang sa kanila ay nag-iiwan ng kalahati ng ruta na hindi tinukoy at lumilikha ng mga bahagyang pagkabigong pinakamahirap iugnay.

Sa rutang pabalik bumabagsak ang mga disenyong ito

Stateful ang NAT gateway para sa mga flow na nakita na nito, kaya bumabalik ang mga sagot sa palabas na koneksyon nang walang bagong panuntunan sa papasok. Hindi ipinapahayag ng katangiang iyon ang isang lokal na serbisyo sa internet, at ang ituring itong ganoon ay nag-uubos ng isang araw ng isang koponan sa pag-debug ng koneksyong hindi naman mabubuo. Para sa trapikong sinimulan ng kliyente, apat na ruta ang dapat magkasundo: ang lokal na patakaran, ang talaan ng transit gateway, ang talaan ng labasang subnet at ang talaan ng subnet ng NAT. Kapag kulang ang huli, lumalabas ang kahilingan sa gusali habang namamatay ang sagot sa loob ng AWS.

Ipatunay gamit ang tunay na kliyente sa likod ng VPN at tingnan kung anong pampublikong pinagmulang address ang ipinapakita nito. Kung iyon ang elastic IP ng NAT gateway, may pagsasaling nagaganap; kung iba, ibang labasan ang sinusukat mo.

Ang asimetrikong bersyon ng pagkabigong ito ay dapat makilala nang maaga. Kapag ang talaan ng subnet ng NAT ng isang Availability Zone ay may rutang pabalik sa prefix ng kliyente at ang isa ay wala, nagtatagumpay o nabibigo ang mga bagong koneksyon depende sa zone kung saan bumabagsak ang flow, at mali ang pagbasa sa pattern bilang hindi matatag na internet. Ihambing ang mga talaan ng subnet ng bawat zone na pinaglilingkuran mo sa halip na ayusin ang zone kung saan binuksan ang ticket, dahil ang kulang na ruta ang buong depekto at wala nang kailangang baguhin sa kabilang panig.

Kailan mas mainam ang tahasang proxy

Ang HTTP proxy sa isang instans sa labasang VPC ay lehitimong alternatibo at kadalasang mas mura. Isinaayos ang mga kliyente na gamitin ito, binubuksan ng proxy ang sarili nitong koneksyon palabas, at ang rutang pabalik ay problema nito sa halip na palaisipan sa simetrikong pagruruta. Para sa kaunting aplikasyon, inaalis nito ang malaking bahagi ng gawaing transit gateway. Nagbibigay din ito ng pag-log bawat gumagamit na hindi kayang gawin ng NAT gateway.

Hindi ito transparent, gayunman. Anumang bumabalewala sa mga setting ng proxy, at bawat protokol na hindi HTTP, ay hindi susunod sa rutang iyon.

Nakasalalay ang pagpili sa aktwal na sinasalita ng iyong mga aplikasyon at kung gaano karaming pagkakakilanlan ang kailangan sa mga log. Kung saan nagsasalita sila ng HTTP, nakakamit ng proxy ang puwesto nito; kung saan kailangan ng pangkalahatang labasan para sa mga arbitraryong protokol, ang disenyong may transit gateway ang sinusuportahan ng AWS. Ang pagpapasya nito nang maaga ay mas mura kaysa matuklasan pagkatapos maitayo ang mga talaan ng ruta.