AWS Site-to-Site VPN al NAT Gateway: VGW kontraŭ Transit Gateway

Ĉiuj unuafoje desegnas la saman diagramon: VPN en la VPC-on, NAT-gateway eksteren al la interreto, finita. Sed AWS ne subtenas tiun vojon, kiam la VPN finiĝas ĉe virtual private gateway, kaj la fiasko estas tiel kvieta, ke teamoj rekonstruas ĝin pli ol unufoje. La funkcianta dezajno bezonas transit gateway, kio ŝanĝas la pordegon kaj la itinertabelojn ambaŭflanke. Komparu la du formojn antaŭ ol desegni ion.

La topologio, kiu ŝajnas evidenta kaj ne estas subtenata

La dokumentaro pri NAT-gateway de AWS desegnas linion, kiu surprizas ĉiun, kiu konstruis nur unu-VPC-dezajnojn: trafiko el Site-to-Site VPN-konekto ne povas esti enkursigita al NAT-gateway tra virtual private gateway. La speco de pordego, ĉe kiu la VPN finiĝas, decidas ĉu entute ekzistas tradukvojo. La eraro postvivas ĉar la tunela stato estas UP kaj EC2-instance en la sama subneto atingas la interreton sen problemo. Nek unu nek la alia observo testas la rompitan direkton.

En praktiko la paketo alvenas kun fonta adreso el la loka reto kaj trovas neniun subtenatan sekvan hop, kiu tradukus ĝin. Laŭ la tabeloj ĝi estas forĵetata ĉe la elira limo, kaj ĉar la tunelo restas UP dum instance en la sama subneto atingas la interreton, la fiasko estas raportata kiel fajroŝirma problemo de la loka reto.

Virtual private gateway kontraŭ transit gateway

Virtua privata pordego apartenas al unu VPC. Ĝi finas la VPN, instalas itinerojn en la itinertabelojn de tiu VPC kaj haltas tie. Ĝi ne havas alligmodelon, do ĝi ne povas transdoni trafikon al alia VPC aŭ al komuna elira segmento. Tiu unu-VPC-amplekso estas la tuta limigo, kaj neniu itinero aldonita ene de la VPC ŝanĝas ĝin.

Transit gateway estas regiona centro, kie la VPN, ĉiu spoke-VPC kaj VPC de komunaj servoj aperas kiel alligoj. Ĝi havas proprajn itinertabelojn, kiuj elektas, kiu alligo ricevas donitan prefikson.

Tiu centro ebligas centralizitan eliron: la VPN surteriĝas kiel unu alligo, la elira VPC kiel alia, kaj itinertabelo de transit gateway sendas interret-renditajn prefiksojn de la unua al la dua. Kun virtual private gateway mankas dua alligo, al kiu sendi ion, tial la dezajno ne povas esti flikita poste.

La subtenata elirvojo, hop post hop

La referenca dezajno havas kvin hopojn kaj ĉiu sago estas enkursiga decido, kiun vi devas agordi. Trafiko lasas la lokan reton en la Site-to-Site VPN-alligon, la itinertabelo de transit gateway plusendas ĝin al la elira VPC-alligo, kie la subnettabelo sendas ĝin al publika NAT-gateway. La NAT-gateway tradukas la fonton kaj la interreta pordego elportas la paketon.

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

Du detaloj decidas ĉu la lastaj hopoj funkcias. La NAT-gateway devas esti publika, kun elastic IP kaj itinero al interreta pordego, ĉar privata NAT-gateway tradukas inter retoj kaj neniam fariĝas interreta elirejo.

Planu unu NAT-gateway por ĉiu Availability Zone, kiun vi intencas servi, kaj ĉiu subnettabelo montru al la loka. Tenadu la transit-gateway-tabelon kaj la VPC-tabelojn kiel apartajn objektojn en viaj notoj, ĉar unu elektas alligon kaj la alia rimedon ene de la VPC. Defaŭlta itinero nur en unu el ili lasas duonon de la vojo nedifinita kaj produktas la partajn fiaskojn, kiujn plej malfacilas atribui.

La revena vojo estas kie tiuj dezajnoj fiaskas

NAT-gateway memoras staton por fluoj, kiujn ĝi jam vidis, do respondoj al elira konekto revenas sen nova enira regulo. Tiu eco ne publikigas lokan servon al la interreto, kaj trakti ĝin kvazaŭ ĝi farus kostas al teamo tutan tagon da sencimigado de konekto, kiu neniam estiĝus. Por klient-iniciatita trafiko kvar itineroj devas kongrui: la loka politiko, la transit-gateway-tabelo, la elira subnettabelo kaj la NAT-subnettabelo. Mankigu la lastan kaj la peto lasas la konstruaĵon, dum la respondo mortas ene de AWS.

Validigu per reala kliento malantaŭ la VPN kaj rigardu, kiun publikan fontadreson ĝi prezentas. Se ĝi estas la elastic IP de la NAT-gateway, tradukado okazas; se io alia, vi mezuras alian eliron.

La nesimetria versio de tiu fiasko indas esti rekonata frue. Kiam la NAT-subnettabelo de unu Availability Zone havas la revenan itineron al la klienta prefikso kaj alia ne, novaj konektoj sukcesas aŭ fiaskas laŭ la zono, en kiun la fluo falas, kaj la ŝablono estas mislegata kiel malfirma interreto. Komparu la subnettabelojn por ĉiu zono, kiun vi servas, anstataŭ ripari tiun, kie la bileto estis malfermita, ĉar la mankanta itinero estas la tuta difekto kaj ĉe la alia flanko nenio bezonas ŝanĝiĝi.

Kiam eksplicita prokuro estas la pli bona dezajno

HTTP-prokuro sur instance en la elira VPC estas legitima alternativo kaj ofte la pli malmultekosta. Klientoj agordiĝas por uzi ĝin, la prokuro malfermas sian propran konekton eksteren, kaj la revena vojo estas ĝia problemo anstataŭ simetria enkursiga enigmo. Por malmultaj aplikaĵoj tio forigas la plejparton de la laboro pri transit gateway. Ĝi ankaŭ donas protokolojn laŭ uzanto, kiujn NAT-gateway ne povas produkti.

Sed ĝi ne estas travidebla. Ĉio, kio ignoras prokurajn agordojn, kaj ĉiu protokolo, kiu ne estas HTTP, ne sekvos tiun vojon.

La elekto dependas de tio, kion viaj aplikaĵoj efektive parolas kaj kiom da identeco vi bezonas en la protokoloj. Kie ili parolas HTTP, la prokuro gajnas sian lokon; kie vi bezonas ĝeneralan eliron por arbitraj protokoloj, la dezajno kun transit gateway estas tiu, kiun AWS subtenas. Decidi tion antaŭe estas pli malmultekoste ol malkovri ĝin post ol la itinertabeloj estas konstruitaj.