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

Alle tegner samme diagram første gang: VPN inn i VPC-en, NAT-gateway ut til internett, ferdig. AWS støtter ikke den veien når VPN-en terminerer på en virtuell privat gateway, og feilen er så stille at team bygger den på nytt mer enn én gang. Designet som virker, krever en transit gateway, og det endrer gatewayen og rutetabellene på begge sider. Sammenlign de to formene før du tegner noe.

Topologien som ser opplagt ut og ikke støttes

AWS' dokumentasjon for NAT-gatewayen trekker en linje som overrasker alle som bare har bygget design med én VPC: trafikk fra en Site-to-Site VPN-forbindelse kan ikke rutes til en NAT-gateway gjennom en virtuell privat gateway. Gatewaytypen VPN-en terminerer på avgjør om det i det hele tatt finnes en oversettelsesvei. Feilen overlever fordi tunnelen er UP og en EC2-instans i samme subnet når internett uten problemer. Ingen av de to observasjonene tester retningen som er ødelagt.

I praksis ankommer pakken med en kildeadresse fra det lokale nettet og finner ikke et støttet neste hopp som ville oversette den. Avhengig av tabellene forkastes den ved utgangsgrensen, og fordi tunnelen blir UP mens en instans i samme subnet fortsatt når internett, rapporteres feilen som et brannmurproblem på den lokale siden.

Virtuell privat gateway kontra transit gateway

En virtuell privat gateway tilhører én VPC. Den terminerer VPN-en, installerer ruter i den VPC-ens rutetabeller og stopper der. Den har ingen attachment-modell, så den kan ikke overlevere trafikk til en annen VPC eller til et delt utgangssegment. Denne enkelt-VPC-utstrekningen er hele begrensningen, og ingen rute du legger til inne i VPC-en endrer det.

En transit gateway er et regionalt knutepunkt der VPN-en, hver spoke-VPC og en VPC for delte tjenester alle vises som attachments. Den har egne rutetabeller, som velger hvilken attachment som mottar et gitt prefiks.

Det knutepunktet er det som gjør sentralisert utgang mulig: VPN-en lander som én attachment, utgangs-VPC-en som en annen, og en rutetabell i transit gateway sender internettrettede prefikser fra den første til den andre. Med en virtuell privat gateway finnes det ingen annen attachment å sende noe til, og derfor kan ikke designet lappes på plass etterpå.

Den støttede utgangsveien, hopp for hopp

Referansedesignet har fem hopp, og hver pil er en rutingsbeslutning du må konfigurere. Trafikken forlater det lokale nettet inn i Site-to-Site VPN-attachmentet, transit gateway-tabellen videresender den til utgangs-VPC-attachmentet, der subnet-tabellen sender den til en offentlig NAT-gateway. NAT-gatewayen oversetter kilden, og internettgatewayen bærer pakken 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

To detaljer avgjør om de siste hoppene virker. NAT-gatewayen må være offentlig, med en elastisk IP og en rute til en internettgateway, fordi en privat NAT-gateway oversetter mellom nettverk og aldri blir en internettutgang.

Planlegg én NAT-gateway per Availability Zone du vil betjene, med hver subnet-tabell som peker på den lokale. Hold transit gateway-tabellen og VPC-tabellene som separate objekter i notatene dine, fordi den ene velger en attachment og den andre velger en ressurs inne i VPC-en. En standardrute i bare én av dem lar halve veien være udefinert og gir de delvise feilene som er vanskeligst å tilskrive.

Det er på returveien disse designene svikter

En NAT-gateway er stateful for strømmer den allerede har sett, så svar på en utgående forbindelse kommer tilbake uten en ny inngående regel. Den egenskapen publiserer ikke en lokal tjeneste på internett, og å behandle den som om den gjør det, er hvordan et team bruker en dag på å feilsøke en forbindelse som aldri ville blitt opprettet. For klientinitiert trafikk må fire ruter stemme: den lokale policyen, transit gateway-tabellen, utgangs-subnet-tabellen og NAT-subnet-tabellen. Mangler den siste, forlater forespørselen bygningen mens svaret dør inne i AWS.

Valider med en ekte klient bak VPN-en og se hvilken offentlig kildeadresse den presenterer. Er den NAT-gatewayens elastiske IP, skjer oversettelse; er den noe annet, måler du en annen utgang.

Den asymmetriske varianten av denne feilen er verdt å kjenne igjen tidlig. Når NAT-subnet-tabellen i én Availability Zone har returruten til klientprefikset og en annen ikke, lykkes eller feiler nye forbindelser avhengig av hvilken sone strømmen lander i, og mønsteret leses feil som ustabilt internett. Sammenlign subnet-tabellene for hver sone du betjener i stedet for å reparere den der saken ble opprettet, fordi den manglende ruten er hele feilen og ingenting på den andre siden trenger å endres.

Når en eksplisitt proxy er det bedre designet

En HTTP-proxy på en instans i utgangs-VPC-en er et legitimt alternativ og ofte billigere. Klienter konfigureres til å bruke den, proxyen åpner sin egen forbindelse utover, og returveien blir dens problem i stedet for et symmetrisk rutingspuslespill. For få applikasjoner fjerner det mesteparten av transit-gateway-arbeidet. Det gir også logging per bruker som en NAT-gateway ikke kan produsere.

Den er likevel ikke transparent. Alt som ignorerer proxyinnstillinger, og enhver protokoll som ikke er HTTP, vil ikke følge den veien.

Valget avhenger av hva applikasjonene dine faktisk snakker, og hvor mye identitet du trenger i loggene. Der de snakker HTTP, fortjener proxyen plassen sin; der du trenger generell utgang for vilkårlige protokoller, er transit gateway-designet det AWS støtter. Å avgjøre det på forhånd er billigere enn å oppdage det etter at rutetabellene er bygget.