Interconexión y gateway de tránsito

Una conexión entre pares (VPC peering) une exactamente dos VPC. Si A está conectada con B y B con C, A no llega a C pasando por B: la relación no es transitiva, y no hay manera de hacerla transitiva con rutas. Para que A y C se vean hace falta otra conexión entre ellas.

Además, cada conexión necesita dos rutas: una en la tabla de cada VPC hacia el rango de la otra. Y los rangos de direcciones de las dos VPC no pueden solaparse. Estas tres reglas explican casi todas las conexiones de pares «activas» que no llevan tráfico.

Una conexión puede aparecer como active y aun así no transportar nada si una de las dos tablas no tiene la ruta hacia el rango del otro lado: los paquetes salen, llegan y la respuesta no encuentra camino de regreso. En la exportación, la tabla rutas_de_peering lista las rutas de cada VPC, la local y las que apuntan a una conexión.

Abre el laboratorio y revisa, para cada conexión activa, que ambos lados tengan su ruta.

AWS no permite crear una conexión de pares entre dos VPC cuyos rangos se solapan, ni tiene sentido enrutar a dos redes con la misma dirección: el router no sabría a cuál mandar el paquete. Es el error clásico de crear VPC «de prueba» con el rango por defecto o con un trozo de otro.

Compara en la tabla vpcs el rango de cada VPC con el de producción. Un rango está dentro de otro si sus primeros bits coinciden: 10.30.64.0/18 comienza donde empieza una parte del bloque 10.30.0.0/16.

Una puerta de enlace de tránsito tiene tablas de rutas y cada tabla puede contener tres tipos de entrada: propagadas (el adjunto anuncia su rango), estáticas (alguien las escribió) y blackhole, una ruta estática que descarta el tráfico hacia ese destino. Sirven para cortar a propósito un rango, por ejemplo uno que ya no debería ser alcanzable, y son una buena señal cuando están documentadas.

En la tabla rutas_tgw, la tabla de producción tiene una ruta de ese tipo.

En la puerta de enlace de tránsito cada adjunto se asocia a una sola tabla (la que se consulta para su tráfico saliente) y puede propagar su rango en una o varias. Un adjunto que propaga su rango en una tabla hace que quien use esa tabla pueda enrutar hacia él. Por eso la política de segmentación se lee en las columnas tabla_asociada y propaga_en.

La política de Envases Ñandubay es que los adjuntos del entorno de pruebas no deben aparecer en la tabla de producción.