AWS Site-to-Site VPN na NAT-gateway: VGW teenoor Transit Gateway

Almal teken die eerste keer dieselfde diagram: VPN in die VPC in, NAT-gateway uit na die internet, klaar. AWS ondersteun nie daardie roete wanneer die VPN op ’n virtuele private gateway eindig nie, en die fout is stil genoeg dat spanne dit meer as een keer herbou. Die ontwerp wat werk, benodig ’n transit gateway, wat die gateway en die roettabelle aan beide kante verander. Vergelyk die twee vorms voordat jy iets teken.

Die topologie wat ooglopend lyk en tog nie ondersteun word nie

AWS se dokumentasie vir die NAT-gateway trek ’n lyn wat elkeen verras wat net ontwerpe vir ’n enkele VPC gebou het: verkeer van ’n Site-to-Site VPN-verbinding kan nie deur ’n virtuele private gateway na ’n NAT-gateway gestuur word nie. Die tipe gateway waarop die VPN eindig, bepaal of daar hoegenaamd ’n translasieroete bestaan. Die fout oorleef omdat die tonnelstatus UP is en ’n EC2-instansie in dieselfde subnet die internet sonder probleme bereik. Nie een van die twee waarnemings toets die rigting wat stukkend is nie.

In die praktyk kom die pakket met ’n bronadres van die perseel af en vind geen ondersteunde volgende sprong wat dit sou vertaal nie. Afhangend van die tabelle word dit by die uitganggrens laat val, en omdat die tonnel UP bly terwyl ’n instansie in dieselfde subnet steeds die internet bereik, word die fout as ’n firewallprobleem aan die perseelkant gerapporteer.

Virtuele private gateway teenoor transit gateway

’n Virtuele private gateway behoort aan een VPC. Dit eindig die VPN, installeer roetes in daardie VPC se roettabelle en stop daar. Dit het geen aanhegtingmodel nie, so dit kan nie verkeer aan ’n ander VPC of aan ’n gedeelde uitgangsegment oorhandig nie. Daardie omvang van een enkele VPC is die hele beperking, en geen roete wat jy binne die VPC byvoeg, verander dit nie.

’n Transit gateway is ’n streekspunt waar die VPN, elke spoke-VPC en ’n VPC vir gedeelde dienste almal as aanhegtings verskyn. Dit het sy eie roettabelle, wat die aanhegting kies wat ’n gegewe prefiks ontvang.

Daardie punt is wat gesentraliseerde uitgang moontlik maak. Die VPN land as een aanhegting, die uitgang-VPC land as ’n ander, en ’n transit-gateway-roottabel stuur internetgerigte prefikse van die eerste na die tweede. Met ’n virtuele private gateway is daar geen tweede aanhegting om iets na te stuur nie, en daarom kan die ontwerp nie agterna ingepas word nie.

Die ondersteunde uitgangroete, sprong vir sprong

Die verwysingsontwerp het vyf spronge, en elke pyl is ’n roetebesluit wat jy moet konfigureer. Verkeer verlaat die perseelnetwerk na die Site-to-Site VPN-aanhegting. Die transit-gateway-roottabel stuur dit na die uitgang-VPC-aanhegting, waar die subnettabel dit na ’n openbare NAT-gateway stuur. Die NAT-gateway vertaal die bron en die internetgateway dra die pakket uit.

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

Twee besonderhede bepaal of die laaste spronge werk. Die NAT-gateway moet openbaar wees, met ’n elastiese IP en ’n roete na ’n internetgateway, want ’n private NAT-gateway vertaal tussen netwerke en word nooit ’n internetuitgang nie.

Beplan een NAT-gateway per Beskikbaarheidsone wat jy bedoel om te bedien, met elke subnettabel wat na die plaaslike een wys. Hou die transit-gateway-tabel en die VPC-tabelle as aparte objekte in jou notas, want die een kies ’n aanhegting en die ander kies ’n hulpbron binne die VPC. ’n Verstekroete in net een van hulle laat die helfte van die roete ongedefinieer en lewer die gedeeltelike foute wat die moeilikste is om toe te skryf.

Die terugroete is waar hierdie ontwerpe misluk

’n NAT-gateway is stateful vir strome wat dit reeds gesien het, so antwoorde op ’n uitgaande verbinding keer terug sonder ’n nuwe inkomende reël. Daardie eienskap publiseer nie ’n perseeldiens na die internet nie, en om dit te behandel asof dit dit doen, is hoe ’n span ’n dag spandeer om ’n verbinding te ontfout wat nooit sou opstel nie. Vir verkeer wat by die kliënt begin, moet vier roetes saamstem: die perseelbeleid, die transit-gateway-tabel, die uitgang-subnettabel en die NAT-subnettabel. Mis die laaste een en die versoek verlaat die gebou terwyl die antwoord binne AWS sterf.

Valideer met ’n werklike kliënt agter die VPN en kyk na die openbare bronadres wat dit voorhou. As daardie adres die elastiese IP van die NAT-gateway is, vind translasie plaas; as dit iets anders is, meet jy ’n ander uitgang.

Die asimmetriese weergawe van hierdie fout is vroeg die moeite werd om te herken. Wanneer een Beskikbaarheidsone se NAT-subnettabel die roete terug na die kliëntprefiks het en ’n ander nie, slaag of misluk nuwe verbindings na gelang van die one waarin die stroom beland, en die patroon word verkeerd gelees as wispelturige internet. Vergelyk die subnettabelle vir elke one wat jy bedien eerder as om die een reg te maak waar die kaartjie oopgemaak is, want ’n ontbrekende roete is die hele fout en niks aan die ander kant hoef te verander nie.

Wanneer ’n eksplisiete instaanbediener die beter ontwerp is

’n HTTP-instaanbediener op ’n instansie in die uitgang-VPC is ’n geldige alternatief en dikwels die goedkoopste. Kliënte word gekonfigureer om dit te gebruik, die instaanbediener maak sy eie verbinding na buite oop, en die terugroete is die instaanbediener se probleem eerder as ’n simmetriese roetepaneel. Vir ’n klein aantal toepassings verwyder dit meeste van die transit-gateway-werk. Dit gee jou ook per-gebruiker-logging wat ’n NAT-gateway nie kan lewer nie.

Dit is egter nie deursigtig nie. Enigiets wat instaanbedienerinstellings ignoreer, en elke protokol wat nie HTTP is nie, sal nie daardie roete volg nie.

Die keuse kom neer op wat jou toepassings werklik praat en hoeveel identiteit jy in die logs nodig het. Waar hulle HTTP praat, verdien die instaanbediener sy plek; waar jy algemene uitgang vir willekeurige protokolle nodig het, is die transit-gateway-ontwerp die een wat AWS ondersteun. Om dit vooraf te besluit is goedkoper as om dit te ontdek nadat die roettabelle gebou is.