Solucionar problemas de conectividad en la VPC

Un servidor de aplicación en una subred privada no logra abrir una conexión a una instancia RDS de la misma VPC. La base de datos está corriendo, las credenciales no cambiaron, y la conexión simplemente expira. Tienes 4 sospechosos y cero evidencia: un security group, una network ACL, una route table, y la posibilidad de que la base de datos ni siquiera esté escuchando.

La mayoría de los ingenieros empieza a hacer clic en la consola en el orden en que aparecen las pestañas. Eso funciona, eventualmente. También quema los primeros 20 minutos de una caída revisando componentes que nunca estuvieron involucrados. La habilidad que enseña esta lección no es memorizar más servicios. Es recorrer el camino en el orden en que lo recorre un paquete, para que lo primero que encuentres mal sea de verdad lo que se rompió.

El camino tiene un orden, y tú también deberías

Un paquete que sale de una instancia EC2 pasa por una secuencia fija de puertas. Cada una puede negarlo, y cada negación se ve idéntica desde la aplicación: un timeout. Así que trabaja la secuencia, no tu intuición.

1. Security group de origen, salida. ¿Hay una regla de egress que permita la dirección y el puerto de destino? Los grupos por defecto permiten toda la salida, así que este solo es sospechoso en un entorno restringido. Cuando es la causa, es porque alguien reemplazó la regla de salida por defecto y se olvidó de un puerto.
2. Network ACL de la subred de origen, salida. ¿Hay una regla de salida que permita la solicitud, y una de entrada que permita la respuesta en los puertos efímeros? Las network ACLs no tienen estado, así que son 2 preguntas separadas.
3. Route table de origen. ¿Hay una ruta cuyo CIDR de destino contenga la dirección buscada, y su target existe y funciona? Sin ruta, el paquete se descarta antes de que se consulte firewall alguno.
4. El intermediario. NAT gateway, internet gateway, VPC endpoint, conexión de peering o transit gateway. Cada uno tiene sus propios modos de falla, y cada uno se cubrió en los temas anteriores de este dominio.
5. Network ACL de la subred de destino, entrada. El mismo par de preguntas sin estado, desde el otro lado.
6. Security group de destino, entrada. ¿Hay una regla de ingress que permita el origen, ya sea por CIDR o referenciando el security group de origen?
7. La política del recurso. Una endpoint policy, una bucket policy de S3 o una política del lado del servicio pueden rechazar una solicitud cuyos paquetes llegaron perfectos. Esta produce un error en lugar de un timeout, que ya es una señal útil por sí sola.

Después recorre el camino de regreso. Suena a formalidad hasta que conoces la falla que atrapa: la solicitud se acepta, el destino responde, y la respuesta la niega una regla de salida de network ACL en la que nadie pensó porque la aplicación solo inicia en una dirección.

Este orden paga porque cada puerta esconde a las que tiene atrás. Si la route table no tiene coincidencia, el security group del extremo lejano puede estar abierto de par en par o cerrado y nunca lo sabrías. Revisar en orden del camino significa que la primera negación que encuentras es la que importa, y todo lo que viene después es ruido.

Lee el síntoma antes de leer la configuración

Tres de las fallas de arriba producen síntomas distinguibles si miras lo correcto.

La segunda fila merece su propia frase, porque ahorra investigaciones enteras. Un error de conexión rechazada significa que la red funcionó. El SYN llegó al host, el host no tenía nada escuchando en ese puerto, y respondió con honestidad. Ningún security group produce ese error, porque una denegación de security group produce silencio. Cuando una aplicación registra connection refused, deja de mirar la VPC y anda a ver si el proceso está corriendo y escuchando en la dirección que crees.

Reachability Analyzer lee el camino completo por ti

Recorrer 7 puertas a mano, a veces cruzando 2 cuentas, toma tiempo real. Reachability Analyzer lo hace en una sola llamada.

Lo importante de entender es qué mira en realidad. Arma un modelo de la configuración de tu red y razona sobre ese modelo. No manda paquetes y no toca el plano de datos. Así que puede decirte que un security group descartaría este tráfico, y puede darte el camino salto por salto que tomaría un paquete permitido, sin que exista tráfico alguno. Por eso funciona sobre un recurso completamente roto, y por eso funciona antes de que despliegues nada real.

Defines un path: un origen, un destino y, si quieres, un protocolo, un puerto de destino y componentes intermedios a incluir o excluir. Después corres un analysis sobre ese path. Los orígenes y destinos admitidos son instancias EC2, internet gateways, interfaces de red, transit gateways, attachments de transit gateway, virtual private gateways, VPC endpoint services, VPC endpoints y conexiones de peering, más una dirección IP simple como destino.

# 1. Define el path una sola vez
aws ec2 create-network-insights-path \
  --source i-0a1b2c3d4e5f67890 \
  --destination i-09876fedcba543210 \
  --destination-port 3306 \
  --protocol tcp

# 2. Corre un analysis contra el path, tantas veces como quieras
aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0abc123def456789a

# 3. Lee el veredicto y las explicaciones
aws ec2 describe-network-insights-analyses \
  --network-insights-analysis-ids nia-0abc123def456789a \
  --query 'NetworkInsightsAnalyses[0].[NetworkPathFound,Explanations]'

Tres hechos operativos vale la pena cargar:

• Se te cobra por análisis ejecutado, no por path, así que el objeto path sale gratis de conservar y volver a correr después de cada cambio. Eso es lo que lo vuelve útil como chequeo de regresión y no solo como herramienta de incidente.
• El origen y el destino tienen que estar en la misma región, y en la misma VPC o en VPCs conectadas por peering o por un transit gateway. Pueden estar en cuentas distintas de la misma organización de AWS Organizations si habilitas el acceso confiable.
• Los análisis se borran solos a los 120 días de creados. Si un resultado es evidencia para una auditoría, expórtalo.

Los explanation codes nombran al componente culpable

Cuando un camino no es alcanzable, el análisis devuelve uno o más explanation codes. No necesitas memorizar la lista completa, pero reconocer las familias convierte un muro de salida en un diagnóstico de una línea.

Dos de esos codes enseñan algo más allá de su propio mensaje. MORE_SPECIFIC_ROUTE es la lección de ruteo reformulada como diagnóstico: tu ruta está presente y correcta y aun así sin usar, porque algo más largo coincidió primero. Y TGW_ATTACH_MISSING_TGW_RTB_ASSOCIATION es la distinción entre asociación y propagación de la lección de transit gateway apareciendo como falla concreta, porque un attachment que propaga rutas pero no está asociado a nada no tiene route table que consultar.

Donde termina el modelo y empiezan los paquetes

Reachability Analyzer es un verificador de configuración, así que es ciego a todo lo que no sea configuración. Conocer sus puntos ciegos es lo que evita que un resultado en verde te engañe.

• No considera la salud de los targets registrados. Un load balancer con todos sus targets fallando health checks igual se analiza como alcanzable.
• Solo admite IPv4. Si un recurso tiene las 2 familias de direcciones, solo se analiza el lado IPv4. Una falla exclusiva de IPv6 aparece como NO_PATH.
• No tiene visión de DNS. Si tu aplicación resuelve un nombre a la dirección equivocada, el camino a la dirección correcta sigue siendo perfectamente alcanzable.
• Se detiene en los Connect attachments de transit gateway, y los caminos que pasan por un endpoint de Gateway Load Balancer excluyen al Gateway Load Balancer y a sus targets, que necesitan su propio análisis.
• El soporte de Network Firewall es parcial. Maneja reglas con y sin estado de 5-tupla, pero no listas de dominios, reglas Suricata, opciones de regla ni grupos de recursos por tag, y lo dice en los detalles del path cuando se topa con una.
• No dice nada sobre la aplicación. Un proceso escuchando, un handshake TLS, una base de datos que rechaza las credenciales: todo eso queda fuera del modelo.

Así que la regla honesta es: Reachability Analyzer prueba que el camino está permitido, no que la llamada va a funcionar. Cuando dice no alcanzable, tienes tu respuesta y puedes parar. Cuando dice alcanzable y la aplicación igual falla, también aprendiste algo valioso, que es que el problema está por encima de la capa de red, y los logs de la próxima lección son adonde vas.

Las fallas que no son fallas de red

Cuatro causas explican buena parte de los tickets que llegan etiquetados como "conectividad de VPC" y nunca tocan un security group.

DNS resolviendo a lo que no es. Una private hosted zone necesita enableDnsSupport y enableDnsHostnames en la VPC para ser usable, y un interface endpoint con private DNS deshabilitado deja el nombre público del servicio resolviendo a una dirección pública que una subred privada no puede alcanzar. La conexión falla en la capa de red, pero el arreglo es una configuración de DNS.

Path MTU. Una conexión que abre limpia y después se atasca apenas arranca un payload grande casi nunca es un problema de permisos. Los handshakes son chicos y entran en cualquier lado. Los túneles reducen el tamaño de paquete usable, y si un firewall descarta los mensajes ICMP de fragmentación necesaria, el path MTU discovery no puede avisarle al emisor que mande paquetes más chicos, así que la transferencia se cuelga. Revisa el MTU antes que las reglas cada vez que el síntoma dependa del tamaño.

Source/destination check. Cualquier instancia que reenvía tráfico por cuenta de otros, como una instancia NAT o un appliance, tiene que tenerlo deshabilitado. Si queda activo, la interfaz descarta los paquetes reenviados y todo el ruteo se ve correcto.

Puertos efímeros en una network ACL sin estado. Cubierto completo en la lección de security groups, y reaparece acá porque es la razón número 1 de que una network ACL permita la solicitud y mate la respuesta. Si el tráfico sale y las reglas de entrada de la network ACL no permiten de vuelta el rango 1024 a 65535, nada funciona y cada regla se lee razonable.

Tips de examen

• Recorrido ordenado, siempre. Security group de origen, network ACL de origen, route table, intermediario, network ACL de destino, security group de destino, política del recurso, y después el camino de regreso. Las preguntas de escenario se construyen rompiendo exactamente uno de estos.
• "Connection refused" no es un problema de red. Timeout significa descartado, refused significa entregado. Una pregunta que dice que el cliente recibe un rechazo inmediato apunta al servicio, no a la VPC.
• Reachability Analyzer analiza configuración, no paquetes. Cuando una pregunta pide encontrar el componente que bloquea sin generar tráfico ni cambiar nada, la respuesta es esta. Cuando pregunta qué le pasó al tráfico real, son los flow logs.
• Reachability Analyzer es solo IPv4, misma región, e ignora la salud de los targets. Esas 3 restricciones son lo que más probablemente pregunte el examen sobre la herramienta.
• MORE_SPECIFIC_ROUTE y NO_ROUTE_TO_DESTINATION son ruteo; SUBNET_ACL_RESTRICTION es la network ACL; ENI_SG_RULES_MISMATCH es el security group. Saber mapear un code a un componente alcanza.
• Los CIDR superpuestos no se pueden poner en peering, porque la ruta local siempre gana dentro del CIDR de tu propia VPC y no se puede sobrescribir.
• Appliance que reenvía más descartes silenciosos igual a source/destination check.
• Se cuelga solo en transferencias grandes igual a MTU, no a firewalls.

El hábito que vale llevarse de esta lección es más chico que la lista de herramientas: cuando una conexión falla, nombra la primera puerta del camino que todavía no verificaste, y revisa esa. Reachability Analyzer es como haces ese recorrido en una llamada en lugar de 7. Lo que no te puede decir es qué le pasó al tráfico real el martes pasado a las 03:00, y para eso son los logs de la próxima lección.