AWS Site-to-Site VPN a NAT Gateway: VGW o Transit Gateway

Tothom dibuixa el mateix diagrama el primer cop: VPN cap a la VPC, NAT gateway cap a internet, fet. Però AWS no admet aquest camí quan la VPN acaba en una virtual private gateway, i la fallada és prou silenciosa perquè els equips la refacin més d'un cop. El disseny que funciona necessita una transit gateway, que canvia la gateway i les taules de rutes dels dos costats. Compareu les dues formes abans de dibuixar res.

La topologia que sembla òbvia i no està suportada

La documentació de NAT gateway d'AWS traça una línia que sorprèn qui només ha construït dissenys d'una sola VPC: el trànsit d'una connexió Site-to-Site VPN no es pot encaminar a una NAT gateway a través d'una virtual private gateway. El tipus de gateway on acaba la VPN decideix si existeix cap camí de traducció. L'error sobreviu perquè l'estat del túnel és UP i una instància EC2 de la mateixa subxarxa arriba a internet sense problema. Cap de les dues observacions no prova la direcció trencada.

A la pràctica el paquet arriba amb una adreça d'origen de la xarxa local i no troba cap salt següent admès que el tradueixi. Segons les taules, es descarta a la frontera de sortida i, com que el túnel continua UP mentre una instància de la mateixa subxarxa arriba a internet, la fallada es reporta com un problema de firewall local.

Virtual private gateway versus transit gateway

Una virtual private gateway pertany a una sola VPC. Acaba la VPN, instal·la rutes a les taules d'aquesta VPC i s'atura aquí. No té model d'adjunció, així que no pot lliurar trànsit a una altra VPC ni a un segment de sortida compartit. Aquest abast d'una sola VPC és tota la limitació, i cap ruta que afegiu dins la VPC no la canvia.

Una transit gateway és un concentrador regional on la VPN, cada VPC en spoke i una VPC de serveis compartits apareixen com a adjuncions. Té les seves pròpies taules de rutes, que trien quina adjunció rep un prefix determinat.

Aquest concentrador és el que fa possible la sortida centralitzada. La VPN aterra com una adjunció, la VPC de sortida com una altra, i una taula de rutes de transit gateway envia els prefixos cap a internet de la primera a la segona. Amb una virtual private gateway no hi ha segona adjunció on enviar res, i per això el disseny no es pot apegar després.

El camí de sortida admès, salt a salt

El disseny de referència té cinc salts i cada fletxa és una decisió d'encaminament que heu de configurar. El trànsit surt de la xarxa local cap a l'adjunció Site-to-Site VPN; la taula de rutes de transit gateway el passa a l'adjunció de la VPC de sortida, on la taula de subxarxa l'envia a una NAT gateway pública. La NAT gateway tradueix l'origen i la internet gateway treu el paquet.

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

Dos detalls decideixen si funcionen els últims salts. La NAT gateway ha de ser pública, amb una elastic IP i una ruta a una internet gateway, perquè una NAT gateway privada tradueix entre xarxes i mai no es converteix en sortida a internet.

Planifiqueu una NAT gateway per Availability Zone que vulgueu servir, amb cada taula de subxarxa apuntant a la local. Mantingueu la taula de transit gateway i les taules de la VPC com a objectes separats a les notes, perquè una tria una adjunció i l'altra un recurs dins la VPC. Una ruta per defecte només en una de les dues deixa mig camí indefinit i produeix les fallades parcials més difícils d'atribuir.

El camí de tornada és on fallen aquests dissenys

Una NAT gateway és stateful per als fluxos que ja ha vist, així que les respostes d'una connexió de sortida tornen sense cap regla d'entrada nova. Aquesta propietat no publica un servei local a internet, i tractar-la com si ho fes és com un equip perd un dia depurant una connexió que mai no s'havia d'establir. Per al trànsit originat pel client han de coincidir quatre rutes: la política local, la taula de transit gateway, la taula de subxarxa de sortida i la taula de subxarxa de NAT. Si falla l'última, la petició surt de l'edifici mentre la resposta mor dins d'AWS.

Valideu-ho amb un client real darrere la VPN i mireu quina adreça d'origen pública presenta. Si és l'elastic IP de la NAT gateway, s'està traduint; si és qualsevol altra, mesureu una sortida diferent.

La versió asimètrica d'aquesta fallada val la pena reconèixer-la aviat. Quan la taula de subxarxa NAT d'una Availability Zone té la ruta de tornada al prefix del client i una altra no, les connexions noves funcionen o fallen segons la zona on cau el flux, i el patró es llegeix malament com a internet inestable. Compareu les taules de subxarxa de cada zona que serviu en lloc d'arreglar la que va obrir el tiquet, perquè la ruta que falta és tota la fallada i a l'altre costat no cal canviar res.

Quan un proxy explícit és el millor disseny

Un proxy HTTP en una instància de la VPC de sortida és una alternativa legítima i sovint més barata. Els clients es configuren per usar-lo, el proxy obre la seva pròpia connexió cap enfora i el camí de tornada és el seu problema, no un trencaclosques d'encaminament simètric. Per a unes poques aplicacions això elimina bona part de la feina de transit gateway. També dóna registres per usuari que una NAT gateway no pot produir.

No és transparent, però. Tot el que ignori la configuració del proxy i cada protocol que no sigui HTTP no seguiran aquest camí.

L'elecció depèn de què parlen realment les vostres aplicacions i de quanta identitat necessiteu als registres. On parlen HTTP, el proxy guanya el lloc; on cal sortida general per a protocols arbitraris, el disseny amb transit gateway és el que AWS admet. Decidir-ho d'entrada surt més barat que descobrir-ho quan les taules de rutes ja estan fetes.