Tablas de rutas y rutas asimétricas

Cuando la dirección de destino coincide con más de una ruta de la tabla, AWS elige la más específica, es decir, la de máscara más larga. La ruta local de la VPC siempre existe y no se puede borrar; 0.0.0.0/0 es la menos específica de todas y solo se usa si nada más coincide. El orden en que aparezcan las filas no importa.

Esto permite excepciones útiles (mandar un solo rango pequeño por un firewall) y también accidentes: una ruta estrecha olvidada puede desviar el tráfico de una aplicación sin que nadie lo note.

Para saber por dónde sale un paquete se toma su dirección de destino, se buscan todas las rutas que la contienen y se elige la de máscara más larga. El campo objetivo de esa fila es el siguiente salto: una conexión de pares, un NAT, una puerta de enlace de internet o el endpoint de un firewall.

Abre la tabla rt_nan_apps del laboratorio. Una aplicación de 10.30.1.20 envía un paquete a la base de datos en 10.31.40.9.

Cuando se borra el objetivo de una ruta (una conexión de pares eliminada, un NAT retirado) la ruta no desaparece: queda en estado blackhole y el tráfico hacia ese destino se descarta. Una ruta así es un resto de una obra anterior. Es inofensiva hasta que alguien crea un objetivo nuevo con el mismo destino, o hasta que una caída se atribuye a otra causa.

En la tabla rt_nan_apps, el estado de cada ruta está en la tercera columna.

Toda VPC tiene una tabla principal. Una subred que no tiene una tabla asociada de forma explícita usa esa, sin avisar. Si la tabla principal contiene una ruta a una puerta de enlace de internet, esa subred hereda salida directa a internet aunque nadie la haya diseñado como pública. Por eso en una revisión se compara la lista de asociaciones con las subredes existentes.

Abre las consultas asociaciones y tabla_principal del laboratorio.

Un firewall con estado necesita ver los dos sentidos de una conexión para entenderla. Si los paquetes de ida pasan por él y los de vuelta toman otra ruta (una conexión de pares directa, por ejemplo), el firewall solo ve la mitad: no completa el seguimiento de la conexión y puede descartarla o dejarla sin inspección. Es el fallo clásico de la ruta asimétrica, y se descubre comparando la tabla de cada lado.

En ida_y_vuelta está la captura de un caso: la aplicación 10.30.1.20 hacia la base 10.31.40.9 y su respuesta.