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

Alle teiknar same diagrammet første gongen: VPN inn i VPC-en, NAT-gateway ut til internett, ferdig. Men AWS støttar ikkje den vegen når VPN-en terminerer på ein virtuell privat gateway, og feilen er så stille at team byggjer han på nytt meir enn éin gong. Designet som verkar, krev ein transit gateway, og det endrar gatewayen og rutetabellane på begge sider. Samanlikn dei to formene før du teiknar noko.

Topologien som ser opplagt ut og ikkje blir støtta

AWS sin dokumentasjon for NAT-gatewayen dreg ei linje som overraskar alle som berre har bygt design med éin VPC: trafikk frå ei Site-to-Site VPN-tilkopling kan ikkje rutast til ein NAT-gateway gjennom ein virtuell privat gateway. Gatewaytypen VPN-en terminerer på avgjer om det i det heile finst ein omsetjingsveg. Feilen overlever fordi tunnelen er UP og ein EC2-instans i same subnet når internett utan problem. Ingen av dei to observasjonane testar retninga som er øydelagd.

I praksis kjem pakken med ei kjeldeadresse frå det lokale nettet og finn ikkje eit støtta neste hopp som ville omsetje han. Avhengig av tabellane blir han kasta ved utgangsgrensa, og fordi tunnelen blir UP medan ein instans i same subnet framleis når internett, blir feilen rapportert som eit brannmurproblem på den lokale sida.

Virtuell privat gateway kontra transit gateway

Ein virtuell privat gateway høyrer til éin VPC. Han terminerer VPN-en, installerer ruter i rutetabellane til den VPC-en og stoppar der. Han har ingen attachment-modell, så han kan ikkje overlevere trafikk til ein annan VPC eller til eit delt utgangssegment. Denne éin-VPC-utstrekninga er heile avgrensinga, og inga rute du legg til inne i VPC-en endrar det.

Ein transit gateway er eit regionalt knutepunkt der VPN-en, kvar spoke-VPC og ein VPC for delte tenester alle viser seg som attachments. Han har eigne rutetabellar, som vel kva attachment som får eit gitt prefiks.

Det knutepunktet er det som gjer sentralisert utgang mogleg: VPN-en landar som éin attachment, utgangs-VPC-en som ein annan, og ein rutetabell i transit gateway sender internettretta prefiks frå den første til den andre. Med ein virtuell privat gateway finst det ingen annan attachment å sende noko til, og difor kan ikkje designet lappast på plass etterpå.

Den støtta utgangsvegen, hopp for hopp

Referansedesignet har fem hopp, og kvar pil er eit rutingsval du må konfigurere. Trafikken forlèt det lokale nettet inn i Site-to-Site VPN-attachmentet, transit gateway-tabellen videresender han til utgangs-VPC-attachmentet, der subnet-tabellen sender han til ein offentleg NAT-gateway. NAT-gatewayen omset kjelda, og internettgatewayen ber 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 detaljar avgjer om dei siste hoppa verkar. NAT-gatewayen må vere offentleg, med ein elastisk IP og ei rute til ein internettgateway, fordi ein privat NAT-gateway omset mellom nettverk og aldri blir ein internettutgang.

Planlegg éin NAT-gateway per Availability Zone du vil betene, med kvar subnet-tabell som peikar på den lokale. Hald transit gateway-tabellen og VPC-tabellane som separate objekt i notata dine, fordi den eine vel ein attachment og den andre vel ein ressurs inne i VPC-en. Ei standardrute i berre éin av dei lèt halve vegen vere udefinert og gjev dei delvise feila som er vanskelegast å tilskrive.

Det er på returvegen desse designa sviktar

Ein NAT-gateway er stateful for straumar han allereie har sett, så svar på ei utgåande tilkopling kjem tilbake utan ei ny inngåande regel. Den eigenskapen publiserer ikkje ei lokal teneste på internett, og å handsame han som om han gjer det, er korleis eit team brukar ein dag på å feilsøkje ei tilkopling som aldri ville blitt oppretta. For klientinitiert trafikk må fire ruter stemme: den lokale policyen, transit gateway-tabellen, utgangs-subnet-tabellen og NAT-subnet-tabellen. Manglar den siste, forlèt førespurnaden bygningen medan svaret døyr inne i AWS.

Valider med ein ekte klient bak VPN-en og sjå kva offentleg kjeldeadresse han presenterer. Er ho NAT-gatewayen sin elastiske IP, skjer omsetjing; er ho noko anna, måler du ein annan utgang.

Den asymmetriske varianten av denne feilen er verd å kjenne att tidleg. Når NAT-subnet-tabellen i éin Availability Zone har returruta til klientprefikset og ein annan ikkje, lykkast eller feilar nye tilkoplingar avhengig av kva sone straumen landar i, og mønsteret blir lese feil som ustabilt internett. Samanlikn subnet-tabellane for kvar sone du betener i staden for å reparere den der saka vart oppretta, fordi den manglande ruta er heile feilen og ingenting på den andre sida treng å endrast.

Når ein eksplisitt proxy er det betre designet

Ein HTTP-proxy på ein instans i utgangs-VPC-en er eit legitimt alternativ og ofte billegare. Klientar blir konfigurerte til å bruke han, proxyen opnar si eiga tilkopling utover, og returvegen blir problemet hans i staden for eit symmetrisk rutingspuslespel. For få applikasjonar fjernar det mesteparten av transit-gateway-arbeidet. Det gjev òg logging per brukar som ein NAT-gateway ikkje kan produsere.

Han er likevel ikkje transparent. Alt som ignorerer proxyinnstillingar, og kvar protokoll som ikkje er HTTP, vil ikkje følgje den vegen.

Valet avheng av kva applikasjonane dine faktisk snakkar, og kor mykje identitet du treng i loggane. Der dei snakkar HTTP, fortener proxyen plassen sin; der du treng generell utgang for vilkårlege protokollar, er transit gateway-designet det AWS støttar. Å avgjere det på førehand er billegare enn å oppdage det etter at rutetabellane er bygde.