AWS Site-to-Site VPN op NAT-Gateway: VGW géint Transit Gateway

Jiddereen zeechent déi éischte Kéier dat selwecht Diagramm: VPN an d'VPC, NAT-Gateway eraus an den Internet, fäerdeg. AWS ënnerstëtzt dee Wee awer net, wann d'VPN op enger virtual private gateway ophält, an de Feeler ass sou roueg, datt Teams en méi wéi eng Kéier nei bauen. Den Design, dee funktionéiert, brauch eng transit gateway, an dat ännert d'Gateway an d'Routentabellen op béide Säiten. Vergläicht déi zwou Formen, ier Dir eppes zeechent.

D'Topologie, déi offensichtlech schéngt an net ënnerstëtzt gëtt

Der AWS-Dokumentatioun iwwer d'NAT-Gateway zitt eng Linn, déi jiddereen iwwerrascht, dee just Een-VPC-Designen gebaut huet: Trafic vun enger Site-to-Site-VPN-Verbindung kann net iwwer eng virtual private gateway op eng NAT-Gateway gerout ginn. Den Typ Gateway, op deem d'VPN ophält, decidéiert, ob iwwerhaapt en Iwwersetzungswee existéiert. De Feeler iwwerlieft, well den Tunnelstatus UP ass an eng EC2-Instanz am selwechten Subnet den Internet ouni Problemer erreecht. Keng vun deenen zwee Observatioune testt déi kaputt Richtung.

An der Praxis kënnt de Pak mat enger Quelladress aus dem lokalen Netz un a fënnt keen ënnerstëtzten nächsten Hop, deen en iwwersetze géif. Je no Tabellen gëtt en un der Ausgangsgrenz verworf, a well den Tunnel UP bleift, wärend eng Instanz am selwechten Subnet den Internet erreecht, gëtt de Feeler als Firewallproblem bei der Lokatioun gemellt.

Virtual private gateway géint transit gateway

Eng virtual private gateway gehéiert zu enger eenzeger VPC. Si beendet d'VPN, installéiert Routen an d'Routentabelle vun där VPC a stoppt do. Si huet kee Attachment-Modell, dofir kann si den Trafic weder un eng aner VPC nach un en gedeelt Ausgangssegment iwwerginn. Dës Een-VPC-Reechwäit ass déi ganz Aschränkung, an keng Route bannen an der VPC ännert dat.

Eng transit gateway ass en regionale Hub, wou d'VPN, all Spoke-VPC an eng VPC fir gedeelt Servicer als Attachments erschéngen. Si huet seng eege Routentabellen, déi wielen, wéi en Attachment e bestëmmte Prefix kritt.

Dee Hub mécht de zentraliséierten Ausgang méiglech: d'VPN landt als een Attachment, d'Ausgangs-VPC als en aneren, an eng Routentabell vun der transit gateway schéckt internetgeriicht Prefixe vum éischten op den zweeten. Mat enger virtual private gateway gëtt et keen zweeten Attachment, fir eppes hinzeschécken, dofir kann den Design net duerno gefléckt ginn.

Den ënnerstëtzten Ausgangswee, Hop fir Hop

Den Referenzdesign huet fënnef Hops, an all Feil ass eng Routingentscheedung, déi Dir musst konfiguréieren. Den Trafic verléisst de lokalen Netz an den Site-to-Site-VPN-Attachment, d'Routentabell vun der transit gateway leet en un den Ausgangs-VPC-Attachment weider, wou d'Subnettabell en op eng ëffentlech NAT-Gateway schéckt. D'NAT-Gateway iwwersetzt d'Quell, an d'Internet-Gateway dréit de Pak eraus.

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

Zwee Detailer entscheeden, ob déi lescht Hops funktionéieren. D'NAT-Gateway muss ëffentlech sinn, mat enger elastischer IP an enger Route op eng Internet-Gateway, well eng privat NAT-Gateway tëschent Netzwierker iwwersetzt an ni en Internetausgang gëtt.

Plangt eng NAT-Gateway pro Availability Zone, déi Dir wëllt bedéngen, an all Subnettabell weist op déi lokal. Hält d'Transit-Gateway-Tabell an d'VPC-Tabellen an Ären Notizen als getrennt Objeten, well déi eng en Attachment wielt an déi aner eng Ressource bannen an der VPC. Eng Default-Route nëmmen an enger vun deenen zwee léisst d'Halschent vum Wee ondefinéiert a produzéiert déi deelweis Feeler, déi am schwéiersten zouzeuerdnen sinn.

Um Réckwee falen dës Designen

Eng NAT-Gateway ass stateful fir Flows, déi se schonn gesinn huet, dofir kommen Äntwerten op eng erausgäng Verbindung ouni nei erakomm Regel zréck. Déi Eegenschaft verëffentlecht keen lokalen Service am Internet, an se esou ze behandelen kascht engem Team engem Dag Debugging fir eng Verbindung, déi ni zustane komm wier. Fir Trafic, dee vum Client ugefaang gëtt, mussen véier Routen eens ginn: d'lokal Politik, d'Transit-Gateway-Tabell, d'Ausgangs-Subnettabell an d'NAT-Subnettabell. Verpasst Dir déi lescht, verléisst d'Ufro d'Gebai, während d'Äntwert bannen an AWS stierft.

Validéiert mat engem echte Client hannert der VPN a kuckt, wéi eng ëffentlech Quelladress en duerstellt. Ass et d'elastesch IP vun der NAT-Gateway, geschitt Iwwersetzung; ass et eppes anescht, messt Dir en aneren Ausgang.

D'asymmetresch Versioun vun dësem Feeler ass et wäert, fréi ze erkennen. Wann d'NAT-Subnettabell vun enger Availability Zone d'Réckroute op de Client-Prefix huet an eng aner net, da geléngen oder feelen nei Verbindungen jee no Zone, an déi de Flow fällt, an d'Muster gëtt falsch als onbestännegen Internet gelies. Vergläicht d'Subnettabellen fir all Zone, déi Dir bedéngt, amplaz déi ze flécken, wou den Ticket opgaang ass, well déi fehlend Route de ganze Feeler ass an op der anerer Säit näischt geännert muss ginn.

Wéini en explizitte Proxy den besseren Design ass

En HTTP-Proxy op enger Instanz an der Ausgangs-VPC ass eng legitim Alternativ an dacks déi méi bëlleg. Cliente ginn drop konfiguréiert, de Proxy mécht seng eege Verbindung no baussen op, an de Réckwee ass säi Problem amplaz vun engem Puzzel mat symmetreschem Routing. Fir e puer Applikatiounen eliminéiert dat de gréissten Deel vun der Transit-Gateway-Aarbecht. Et gëtt Iech och Logging pro Benotzer, dat eng NAT-Gateway net ka produzéieren.

Et ass awer net transparent. Alles, wat Proxy-Astellungen ignoréiert, an all Protokoll, dat net HTTP ass, wäert dee Wee net goen.

D'Wiel hänkt dovun of, wat Är Applikatiounen tatsächlech schwätzen a wéi vill Identitéit Dir an de Loggen braucht. Wou se HTTP schwätzen, verdéngt de Proxy seng Plaz; wou Dir allgemengen Ausgang fir arbitréi Protokollen braucht, ass den Transit-Gateway-Design dee vun AWS ënnerstëtzten. Dat viraus ze entscheeden ass méi bëlleg wéi et no dem Bau vun den Routentabellen z'entdecken.