AWS Site-to-Site VPN drejt NAT Gateway: VGW kundrejt Transit Gateway

Të gjithë vizatojnë të njëjtin diagram herën e parë: VPN në VPC, NAT gateway jashtë në internet, mbaroi. Por AWS nuk e mbështet atë rrugë kur VPN përfundon në një virtual private gateway, dhe dështimi është aq i heshtur sa ekipet e rindërtojnë më shumë se një herë. Dizajni që funksionon kërkon një transit gateway, gjë që ndryshon gateway-in dhe tabelat e rrugëve në të dyja anët. Krahasoni dy format përpara se të vizatoni diçka.

Topologjia që duket e qartë dhe nuk mbështetet

Dokumentacioni i NAT gateway i AWS tërheq një vijë që çudit këdo që ka ndërtuar vetëm dizajne me një VPC të vetëm: trafiku nga një lidhje Site-to-Site VPN nuk mund të rrugëzohet drejt një NAT gateway përmes një virtual private gateway. Lloji i gateway-it ku përfundon VPN vendos nëse ekziston fare një rrugë përkthimi. Gabimi mbijeton sepse tuneli është UP dhe një instancë EC2 në të njëjtin subnet arrin internetin pa problem. Asnjëra nga dy vëzhgimet nuk teston drejtimin e prishur.

Në praktikë paketa arrin me një adresë burimi nga rrjeti lokal dhe nuk gjen ndonjë hop të ardhshëm të mbështetur që do ta përkthente. Në varësi të tabelave, hidhet në kufirin e daljes, dhe meqenëse tuneli mbetet UP ndërsa një instancë në të njëjtin subnet arrin internetin, dështimi raportohet si problem firewall-i në anën lokale.

Virtual private gateway kundrejt transit gateway

Një virtual private gateway i përket një VPC-je të vetme. Ai e përfundon VPN, instalon rrugë në tabelat e atij VPC dhe ndalon aty. Nuk ka model attachment, ndaj nuk mund t'ia dorëzojë trafikun një VPC tjetër ose një segmenti daljeje të përbashkët. Kjo shtrirje e një VPC-je është e gjithë kufizimi, dhe asnjë rrugë e shtuar brenda VPC nuk e ndryshon atë.

Transit gateway është një qendër rajonale ku VPN-ja, çdo spoke VPC dhe një VPC shërbimesh të përbashkëta shfaqen si attachments. Ka tabelat e veta të rrugëve, të cilat zgjedhin cili attachment merr një prefix të caktuar.

Kjo qendër bën të mundur daljen e centralizuar: VPN zbarkon si një attachment, VPC-ja e daljes si një tjetër, dhe një tabelë rrugësh e transit gateway i dërgon prefixet drejt internetit nga i pari te i dyti. Me një virtual private gateway nuk ka një attachment të dytë ku të dërgohet diçka, prandaj dizajni nuk mund të rregullohet më vonë.

Rruga e daljes e mbështetur, hop pas hopi

Dizajni referues ka pesë hop dhe çdo shigjetë është një vendim rrugëzimi që duhet ta konfiguroni. Trafiku del nga rrjeti lokal në attachment-in Site-to-Site VPN, tabela e transit gateway e përcjell në attachment-in e VPC-së së daljes, ku tabela e subnet e dërgon në një NAT gateway publik. NAT gateway përkthen burimin dhe internet gateway e nxjerr paketën jashtë.

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

Dy detaje vendosin nëse hop-et e fundit funksionojnë. NAT gateway duhet të jetë publik, me elastic IP dhe një rrugë drejt një internet gateway, sepse një NAT gateway privat përkthen midis rrjeteve dhe nuk bëhet kurrë dalje interneti.

Planifikoni një NAT gateway për çdo Availability Zone që synoni të shërbeni, me çdo tabelë subnet që tregon drejt asaj lokale. Mbajini tabelën e transit gateway dhe tabelat e VPC si objekte të veçanta në shënimet tuaja, sepse njëra zgjedh një attachment dhe tjetra një burim brenda VPC. Një rrugë e paracaktuar vetëm në njërën prej tyre e lë gjysmën e rrugës të papërcaktuar dhe prodhon dështimet e pjesshme që janë më të vështirat për t'u atribuar.

Pikërisht në rrugën e kthimit dështojnë këto dizajne

NAT gateway mban gjendjen për flukset që ka parë tashmë, kështu që përgjigjet për një lidhje dalëse kthehen pa një rregull të re hyrëse. Kjo veti nuk publikon një shërbim lokal në internet, dhe trajtimi i saj sikur ta bëjë kushton një ekip një ditë korrigjimi të një lidhjeje që nuk do të ishte krijuar kurrë. Për trafikun e nisur nga klienti, katër rrugë duhet të bien dakord: politika lokale, tabela e transit gateway, tabela e subnet-it të daljes dhe tabela e subnet-it NAT. Nëse i mungon e fundit, kërkesa largohet nga ndërtesa ndërsa përgjigja vdes brenda AWS.

Verifikojeni me një klient real pas VPN dhe shikoni çfarë adrese burimi publike paraqet. Nëse është elastic IP e NAT gateway, përkthimi po ndodh; nëse është diçka tjetër, po matni një dalje tjetër.

Versioni asimetrik i këtij dështimi ia vlen të njihet herët. Kur tabela e subnet-it NAT të një Availability Zone ka rrugën e kthimit drejt prefix-it të klientit dhe një tjetër nuk e ka, lidhjet e reja suksesohen ose dështojnë sipas zonës ku bie fluksi, dhe modeli lexohet gabimisht si internet i paqëndrueshëm. Krahasoni tabelat e subnet-eve për çdo zonë që shërbeni në vend që të rregulloni atë ku u hap tiketa, sepse rruga që mungon është e gjithë defekti dhe në anën tjetër nuk duhet ndryshuar asgjë.

Kur një proxy i qartë është dizajni më i mirë

Një proxy HTTP në një instancë në VPC-në e daljes është një alternativë legjitime dhe shpesh më e lirë. Klientët konfigurohen ta përdorin, proxy hap lidhjen e vet drejt jashtë, dhe rruga e kthimit bëhet problemi i tij në vend të një enigme rrugëzimi simetrik. Për pak aplikacione kjo heq pjesën më të madhe të punës me transit gateway. Gjithashtu jep regjistrime për përdorues që një NAT gateway nuk mund t'i prodhojë.

Nuk është megjithatë transparent. Çdo gjë që injoron cilësimet e proxy, dhe çdo protokoll që nuk është HTTP, nuk do të ndjekë atë rrugë.

Zgjedhja varet nga çfarë flasin vërtet aplikacionet tuaja dhe sa identitet ju nevojitet në regjistrime. Aty ku flasin HTTP, proxy fiton vendin e vet; aty ku ju nevojitet dalje e përgjithshme për protokolle arbitrare, dizajni me transit gateway është ai që mbështet AWS. Ta vendosësh këtë paraprakisht kushton më pak sesa ta zbulosh pasi të jenë ndërtuar tabelat e rrugëve.