AWS Site-to-Site VPN cara a NAT Gateway: VGW fronte a Transit Gateway

Todos debuxan o mesmo diagrama a primeira vez: VPN cara á VPC, NAT gateway cara a internet, listo. Pero AWS non admite ese camiño cando a VPN remata nunha virtual private gateway, e o fallo é tan silencioso que os equipos o reconstruyen máis dunha vez. O deseño que funciona necesita unha transit gateway, o que cambia a pasarela e as táboas de rutas nos dous lados. Compare as dúas formas antes de debuxar nada.

A topoloxía que parece obvia e non está admitida

A documentación de NAT gateway de AWS traza unha liña que sorprende a quen só construíu deseños dunha soa VPC: o tráfico dunha conexión Site-to-Site VPN non se pode encamiñar a unha NAT gateway a través dunha virtual private gateway. O tipo de pasarela onde remata a VPN decide se existe algún camiño de tradución. O erro sobrevive porque o estado do túnel é UP e unha instancia EC2 da mesma subrede chega a internet sen problema. Ningunha das dúas observacións proba a dirección avariada.

Na práctica o paquete chega cun enderezo de orixe da rede local e non atopa ningún seguinte salto admitido que o traduza. Segundo as táboas, descártase no límite de saída e, como o túnel segue UP mentres unha instancia da mesma subrede chega a internet, o fallo repórtase como un problema de firewall local.

Virtual private gateway fronte a transit gateway

Unha virtual private gateway pertence a unha soa VPC. Remata a VPN, instala rutas nas táboas desa VPC e detense aí. Non ten modelo de anexo, así que non pode entregar tráfico a outra VPC nin a un segmento de saída compartido. Ese alcance dunha soa VPC é toda a limitación, e ningunha ruta que engada dentro da VPC o cambia.

Unha transit gateway é un concentrador rexional onde a VPN, cada VPC en spoke e unha VPC de servizos compartidos aparecen como anexos. Ten as súas propias táboas de rutas, que elixen que anexo recibe un prefixo dado.

Ese concentrador é o que fai posible a saída centralizada. A VPN aterra como un anexo, a VPC de saída como outro, e unha táboa de rutas da transit gateway envía os prefixos cara a internet do primeiro ao segundo. Cunha virtual private gateway non hai un segundo anexo ao que enviar nada, por iso o deseño non se pode parchear despois.

O camiño de saída admitido, salto a salto

O deseño de referencia ten cinco saltos e cada frecha é unha decisión de encamiñamento que debe configurar. O tráfico sae da rede local cara ao anexo Site-to-Site VPN, a táboa da transit gateway reenvíao ao anexo da VPC de saída, onde a táboa de subrede o manda a unha NAT gateway pública. A NAT gateway traduce a orixe e a internet gateway saca o paquete.

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

Dous detalles deciden se funcionan os últimos saltos. A NAT gateway debe ser pública, cunha elastic IP e unha ruta a unha internet gateway, porque unha NAT gateway privada traduce entre redes e nunca se converte en saída a internet.

Planifique unha NAT gateway por Availability Zone que queira atender, con cada táboa de subrede apuntando á local. Manteña a táboa da transit gateway e as táboas da VPC como obxectos separados nas súas notas, porque unha elixe un anexo e a outra un recurso dentro da VPC. Unha ruta por defecto só nunha das dúas deixa medio camiño indefinido e produce os fallos parciais máis difíciles de atribuír.

O camiño de volta é onde fallan estes deseños

Unha NAT gateway é stateful para os fluxos que xa viu, así que as respostas dunha conexión saínte volven sen unha regra de entrada nova. Esa propiedade non publica un servizo local en internet, e tratala como se o fixese é como un equipo perde un día depurando unha conexión que nunca se ía establecer. Para o tráfico orixinado polo cliente deben coincidir catro rutas: a política local, a táboa da transit gateway, a táboa de subrede de saída e a táboa de subrede de NAT. Se falla a última, a petición sae do edificio mentres a resposta morre dentro de AWS.

Valide cun cliente real detrás da VPN e mire que enderezo de orixe pública presenta. Se é a elastic IP da NAT gateway, hai tradución; se é outra cousa, está medindo outra saída.

A versión asimétrica deste fallo convén recoñecela pronto. Cando a táboa de subrede NAT dunha Availability Zone ten a ruta de volta ao prefixo do cliente e outra non, as conexións novas funcionan ou fallan segundo a zona onde cae o fluxo, e o patrón malinterprétase como internet inestable. Compare as táboas de subrede de cada zona que atende en lugar de arranxar a que abriu o ticket, porque a ruta que falta é todo o fallo e no outro lado non hai que cambiar nada.

Cando un proxy explícito é o mellor deseño

Un proxy HTTP nunha instancia da VPC de saída é unha alternativa lexítima e a miúdo máis barata. Os clientes configúranse para usalo, o proxy abre a súa propia conexión cara a fóra e o camiño de volta é o seu problema en vez dun crebacabezas de encamiñamento simétrico. Para poucas aplicacións iso elimina a maior parte do traballo da transit gateway. Tamén dá rexistros por usuario que unha NAT gateway non pode producir.

Non é transparente, porén. Todo o que ignore a configuración do proxy e cada protocolo que non sexa HTTP non seguirán ese camiño.

A elección depende do que falen realmente as súas aplicacións e de canta identidade necesita nos rexistros. Onde falan HTTP, o proxy gaña o seu lugar; onde necesita saída xeral para protocolos arbitrarios, o deseño con transit gateway é o que AWS admite. Decidilo por adiantado é máis barato que descubrilo despois de construír as táboas.