Una VPN de sitio a sitio para varias VPC en AWS Transit Gateway

Dos VPC necesitan la red de la oficina este trimestre, y es en el segundo túnel donde se rompe la estimación. AWS Transit Gateway puede actuar como concentrador de enrutamiento compartido: la VPN se asocia una vez y cada VPC se asocia al mismo concentrador. Así la red local llega a cada VPC asociada mediante una sola conexión. Eso cambia quién es dueño de la decisión de enrutamiento, y esa es la parte que la mayoría de los diseños hace mal.

La asociación de la VPN y las asociaciones de las VPC son objetos separados en la misma puerta de enlace, y por eso las relaciones de enrutamiento deben construirse después.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Por qué el peering no es el atajo que la gente espera

La alternativa tentadora es terminar la VPN en la VPC A y emparejar la VPC B con ella. El peering normal de VPC no ofrece tránsito de extremo a extremo a través de la conexión VPN de A. Un par llega a las direcciones que el propio peering proporciona, y un borde de VPN no es una de ellas. El tránsito es lo que da un concentrador; el peering da un par.

Esa restricción es una propiedad del peering, no una cuota que se pueda subir.

La asociación y la propagación hacen trabajos distintos

Dentro de la puerta de enlace de tránsito, la asociación elige la tabla de rutas que se usa para buscar el tráfico que llega de una asociación. La propagación decide qué tablas reciben los prefijos aprendidos o conectados de una asociación. Una sola asociación puede vincularse a una tabla mientras propaga hacia varias. Confundir las dos es como un diseño acaba con una accesibilidad que nadie había planificado.

Un concentrador pequeño totalmente conectado es el caso fácil.

Ponga cada asociación en una sola tabla y la VPN junto con ambos prefijos de VPC se resuelve limpiamente. Eso también permite accesibilidad entre VPC que la organización quizá nunca quiso, porque una tabla compartida no tiene el concepto de radio.

Las rutas de las cargas de trabajo viven en otro sitio

Cada subred de carga de trabajo todavía necesita su propia ruta hacia la puerta de enlace de tránsito para los prefijos locales previstos. Esas tablas de rutas de las VPC son objetos separados de las tablas propias de la puerta de enlace de tránsito. Añada los prefijos que necesita y conserve las rutas existentes en lugar de sustituir cada destino por un nuevo default. Una ruta de subred tampoco anuncia nada al dispositivo del cliente.

Elija enrutamiento dinámico o estático a propósito; el peering no ofrece ninguno de los dos.

Aísle los radios sin perder el acceso local

Cuando A y B pueden llegar ambos a la oficina pero no deben enrutarse entre sí, divida las tablas. La tabla asociada de la asociación de la VPN contiene los prefijos de las VPC. La tabla asociada de las asociaciones de las VPC contiene los prefijos locales, sin ninguna ruta que una A con B. La propagación produce esa relación, así que nunca hay que aceptar todas las asociaciones predeterminadas.

Esto es aislamiento de enrutamiento y no es autorización de la aplicación.

Los grupos de seguridad, las ACL de red, los cortafuegos de los equipos y los permisos propios de cada servicio siguen decidiendo qué tráfico se admite. Si hace falta inspección, diseñe su ruta admitida de forma explícita en lugar de suponer que el concentrador la realiza.

Lo que el concentrador no arregla

Los planes de direcciones deben seguir sin solaparse, porque el concentrador no permite que un prefijo identifique dos cargas de trabajo. Cada asociación de VPC necesita la cobertura de Availability Zone que esperan sus cargas de trabajo. Con BGP, las rutas del dispositivo del cliente hacia cada prefijo necesario deben coincidir con el diseño y su política de importación. Un anuncio que falta se ve exactamente como un túnel roto.

La conexión VPN y la puerta de enlace de tránsito ahora son infraestructura compartida.

Planifique la redundancia de los túneles, la capacidad de los dispositivos, la monitorización y el mantenimiento en torno a todas las VPC dependientes en lugar de tratar cada una como conectada de forma independiente.

La migración desde un esquema existente con virtual private gateway merece el mismo plan explícito. Construya las asociaciones y las políticas, mueva una ruta de carga de trabajo controlada y confirme las relaciones permitidas y denegadas antes de retirar la ruta antigua. La centralización ayuda cuando da al equipo de red un solo lugar para gestionar la conectividad compartida, y perjudica cuando esconde quién puede llegar a quién tras una única tabla grande.