AWS Site-to-Site VPN till NAT-gateway: VGW kontra Transit Gateway

Alla ritar samma diagram första gången: VPN in i VPC:n, NAT-gateway ut till internet, klart. Men AWS stöder inte den vägen när VPN:en terminerar på en virtuell privat gateway, och felet är så tyst att team bygger om det mer än en gång. Designen som fungerar kräver en transit gateway, vilket ändrar gatewayen och rutttabellerna på båda sidor. Jämför de två formerna innan du ritar något.

Topologin som verkar självklar och inte stöds

AWS dokumentation för NAT-gatewayen drar en linje som överraskar alla som bara byggt designer med en enda VPC: trafik från en Site-to-Site VPN-anslutning kan inte routas till en NAT-gateway genom en virtuell privat gateway. Den gatewaytyp som VPN:en terminerar på avgör om det överhuvudtaget finns en översättningsväg. Felet överlever eftersom tunneln är UP och en EC2-instans i samma subnet når internet utan problem. Ingen av de två observationerna testar den trasiga riktningen.

I praktiken anländer paketet med en källadress från det lokala nätet och hittar inget stött nästa hopp som skulle översätta det. Beroende på tabellerna släpps det vid utgångsgränsen, och eftersom tunneln förblir UP medan en instans i samma subnet når internet rapporteras felet som ett brandväggsproblem på den lokala sidan.

Virtuell privat gateway kontra transit gateway

En virtuell privat gateway tillhör en enda VPC. Den terminerar VPN:en, installerar rutter i den VPC:ns rutttabeller och stannar där. Den har ingen attachment-modell och kan därför inte lämna över trafik till en annan VPC eller till ett delat utgångssegment. Denna en-VPC-omfattning är hela begränsningen, och ingen rutt du lägger till i VPC:n ändrar det.

En transit gateway är ett regionalt nav där VPN:en, varje spoke-VPC och en VPC för delade tjänster alla visas som attachments. Den har egna rutttabeller som väljer vilken attachment som tar emot ett givet prefix.

Det navet gör centraliserad utgång möjlig: VPN:en landar som en attachment, utgångs-VPC:n som en annan, och en rutttabell i transit gateway skickar internetriktade prefix från den första till den andra. Med en virtuell privat gateway finns ingen andra attachment att skicka något till, och därför kan designen inte lagas i efterhand.

Den stödda utgångsvägen, hopp för hopp

Referensdesignen har fem hopp och varje pil är ett routingbeslut du måste konfigurera. Trafiken lämnar det lokala nätet in i Site-to-Site VPN-attachmenten, transit gateway-tabellen vidarebefordrar den till utgångs-VPC-attachmenten, där subnettabellen skickar den till en offentlig NAT-gateway. NAT-gatewayen översätter källan och internetgatewayen bär paketet ut.

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

Två detaljer avgör om de sista hoppen fungerar. NAT-gatewayen måste vara offentlig, med en elastisk IP och en rutt till en internetgateway, eftersom en privat NAT-gateway översätter mellan nät och aldrig blir en internetutgång.

Planera en NAT-gateway per Availability Zone du vill betjäna, med varje subnettabell som pekar på den lokala. Håll transit gateway-tabellen och VPC-tabellerna som separata objekt i dina anteckningar, eftersom den ena väljer en attachment och den andra väljer en resurs inne i VPC:n. En standardrutt i bara en av dem lämnar halva vägen odefinierad och ger de delvisa fel som är svårast att tillskriva.

Det är på returvägen dessa designer fallerar

En NAT-gateway är stateful för flöden den redan sett, så svar på en utgående anslutning kommer tillbaka utan en ny inkommande regel. Den egenskapen publicerar inte en lokal tjänst på internet, och att behandla den som om den gjorde det kostar ett team en dag att felsöka en anslutning som aldrig skulle ha upprättats. För klientinitierad trafik måste fyra rutter stämma: den lokala policyn, transit gateway-tabellen, utgångs-subnettabellen och NAT-subnettabellen. Missar du den sista lämnar begäran byggnaden medan svaret dör inne i AWS.

Validera med en riktig klient bakom VPN:en och se vilken offentlig källadress den presenterar. Är det NAT-gatewayens elastiska IP sker översättning; är det något annat mäter du en annan utgång.

Den asymmetriska varianten av detta fel är värd att känna igen tidigt. När NAT-subnettabellen i en Availability Zone har returrutten till klientprefixet och en annan inte, lyckas eller misslyckas nya anslutningar beroende på vilken zon flödet landar i, och mönstret läses fel som instabilt internet. Jämför subnettabellerna för varje zon du betjänar i stället för att reparera den där ärendet öppnades, eftersom den saknade rutten är hela felet och inget på andra sidan behöver ändras.

När en explicit proxy är den bättre designen

En HTTP-proxy på en instans i utgångs-VPC:n är ett legitimt alternativ och ofta billigare. Klienter konfigureras att använda den, proxyn öppnar sin egen anslutning utåt, och returvägen blir dess problem i stället för ett symmetriskt routingpussel. För få applikationer tar det bort det mesta av transit-gateway-arbetet. Det ger också loggning per användare som en NAT-gateway inte kan producera.

Den är dock inte transparent. Allt som ignorerar proxyinställningar, och varje protokoll som inte är HTTP, följer inte den vägen.

Valet beror på vad dina applikationer faktiskt talar och hur mycket identitet du behöver i loggarna. Där de talar HTTP förtjänar proxyn sin plats; där du behöver allmän utgång för godtyckliga protokoll är transit gateway-designen den som AWS stöder. Att avgöra det i förväg är billigare än att upptäcka det efter att rutttabellerna byggts.