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

Alle tegner det samme diagram første gang: VPN ind i VPC'en, NAT-gateway ud til internettet, færdig. AWS understøtter ikke den vej, når VPN'en terminerer på en virtuel privat gateway, og fejlen er så stille, at teams genopbygger den mere end én gang. Det design, der virker, kræver en transit gateway, hvilket ændrer gatewayen og rutetabellerne på begge sider. Sammenlign de to former, før du tegner noget.

Topologien, der ser indlysende ud og ikke understøttes

AWS' dokumentation for NAT-gatewayen trækker en linje, der overrasker enhver, som kun har bygget design med én VPC: trafik fra en Site-to-Site VPN-forbindelse kan ikke rutes til en NAT-gateway gennem en virtuel privat gateway. Den gatewaytype, VPN'en terminerer på, afgør, om der overhovedet findes en oversættelsesvej. Fejlen overlever, fordi tunnelens status er UP, og en EC2-instans i samme subnet når internettet uden problemer. Ingen af de to observationer tester den retning, der er brudt.

I praksis ankommer pakken med en kildeaddresse fra det lokale netværk og finder ikke et understøttet næste hop, der ville oversætte den. Afhængigt af tabellerne kasseres den ved udgangsgrænsen, og fordi tunnelen bliver UP, mens en instans i samme subnet stadig når internettet, rapporteres fejlen som et firewallproblem i det lokale netværk.

Virtuel privat gateway kontra transit gateway

En virtuel privat gateway tilhører én VPC. Den terminerer VPN'en, installerer ruter i den VPC's rutetabeller og stopper der. Den har ingen attachment-model, så den kan ikke overlevere trafik til en anden VPC eller til et delt udgangssegment. Denne enkelt-VPC-rækkevidde er hele begrænsningen, og ingen rute, du tilføjer inde i VPC'en, ændrer det.

En transit gateway er et regionalt knudepunkt, hvor VPN'en, hver spoke-VPC og en VPC til delte tjenester alle optræder som attachments. Den har sine egne rutetabeller, som vælger den attachment, der modtager et givet præfiks.

Det knudepunkt er det, der gør centraliseret udgang mulig. VPN'en lander som én attachment, udgangs-VPC'en som en anden, og en transit-gateway-rutetabel sender internetrettede præfikser fra den første til den anden. Med en virtuel privat gateway er der ingen anden attachment at sende noget til, og derfor kan designet ikke lappes på plads bagefter.

Den understøttede udgangsvej, hop for hop

Referencedesignet har fem hop, og hver pil er en routingbeslutning, du skal konfigurere. Trafikken forlader det lokale netværk ind i Site-to-Site VPN-attachmentet. Transit-gateway-rutetabellen videresender den til udgangs-VPC-attachmentet, hvor subnet-tabellen sender den til en offentlig NAT-gateway. NAT-gatewayen oversætter kilden, og internetgatewayen bærer pakken ud.

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

To detaljer afgør, om de sidste hop virker. NAT-gatewayen skal være offentlig, med en elastisk IP og en rute til en internetgateway, fordi en privat NAT-gateway oversætter mellem netværk og aldrig bliver en internetudgang.

Planlæg én NAT-gateway pr. Availability Zone, du vil betjene, med hver subnet-tabel pegende på den lokale. Hold transit-gateway-tabellen og VPC-tabellerne som separate objekter i dine noter, fordi den ene vælger en attachment og den anden vælger en ressource inde i VPC'en. En standardrute i kun én af dem lader halvdelen af vejen være udefineret og giver de delvise fejl, der er sværest at henføre.

Returvejen er, hvor disse design fejler

En NAT-gateway er stateful for flows, den allerede har set, så svar på en udgående forbindelse vender tilbage uden en ny indgående regel. Den egenskab offentliggør ikke en lokal tjeneste på internettet, og at behandle den som om den gjorde, er hvordan et team bruger en dag på at fejlfinde en forbindelse, der aldrig ville blive oprettet. For klientinitieret trafik skal fire ruter stemme overens: den lokale politik, transit-gateway-tabellen, udgangs-subnet-tabellen og NAT-subnet-tabellen. Mangler den sidste, forlader anmodningen bygningen, mens svaret dør inde i AWS.

Validér med en rigtig klient bag VPN'en og se, hvilken offentlig kildeaddresse den fremviser. Er den NAT-gatewayens elastiske IP, sker der oversættelse; er den noget andet, måler du en anden udgang.

Den asymmetriske version af denne fejl er værd at genkende tidligt. Når én Availability Zones NAT-subnet-tabel har returruten til klientpræfikset og en anden ikke, lykkes eller fejler nye forbindelser afhængigt af, hvilken zone flowet lander i, og mønsteret læses fejlagtigt som ustabilt internet. Sammenlign subnet-tabellerne for hver zone, du betjener, i stedet for at rette den, hvor billetten blev oprettet, fordi den manglende rute er hele fejlen, og intet på den anden side skal ændres.

Hvornår en eksplicit proxy er det bedre design

En HTTP-proxy på en instans i udgangs-VPC'en er et legitimt alternativ og ofte det billigere. Klienter konfigureres til at bruge den, proxyen åbner sin egen forbindelse udad, og returvejen er proxyens problem snarere end et symmetrisk routingpuslespil. For få applikationer fjerner det det meste af transit-gateway-arbejdet. Det giver også logning pr. bruger, som en NAT-gateway ikke kan producere.

Den er dog ikke transparent. Alt, der ignorerer proxyindstillinger, og enhver protokol, der ikke er HTTP, følger ikke den vej.

Valget afhænger af, hvad dine applikationer faktisk taler, og hvor meget identitet du har brug for i loggene. Taler de HTTP, fortjener proxyen sin plads; har du brug for generel udgang til vilkårlige protokoller, er transit-gateway-designet det, AWS understøtter. At beslutte det på forhånd er billigere end at opdage det, efter rutetabellerne er bygget.