Diagnóstico de problemas de conectividad de instancias EC2: Grupos de seguridad y Listas de control de acceso a la red

Conectarse a una instancia de Amazon Elastic Compute Cloud (EC2) es una operación fundamental, sin embargo, los fallos de conectividad se encuentran entre los escenarios de resolución de problemas más comunes para los usuarios de AWS. Cuando una instancia parece estar funcionando correctamente pero permanece inalcanzable, ya sea a través de SSH, RDP o tráfico de aplicaciones, el problema casi siempre reside en las capas de seguridad de red circundantes. Esta guía completa describe el enfoque sistemático para diagnosticar y resolver problemas de conectividad centrándose en los tres puntos de control de red críticos: Grupos de seguridad (SG), Listas de control de acceso a la red (NACL) y Tablas de rutas de VPC.

Comprender la jerarquía y la función de estos controles es clave. Los Grupos de seguridad actúan como firewalls con estado a nivel de instancia, mientras que las NACL actúan como firewalls sin estado a nivel de subred. Las configuraciones erróneas en cualquiera de estos componentes, o rutas de enrutamiento incorrectas, bloquearán inmediatamente el tráfico esperado, lo que provocará frustrantes tiempos de espera en la conexión.

Los tres pilares del control de conectividad de EC2

Antes de profundizar en configuraciones específicas, es crucial comprender el papel que desempeña cada componente en la ruta del tráfico hacia su instancia EC2:

1. Tablas de rutas: determinan a dónde se dirige el tráfico de red en función de su dirección IP de destino. Si el tráfico destinado a Internet o a su IP de cliente no puede alcanzar la puerta de enlace de subred correcta, la conectividad fallará.
2. Listas de control de acceso a la red (NACL): aplican reglas a toda una subred. Son sin estado, lo que significa que tanto el tráfico entrante como el saliente deben permitirse explícitamente. Procesan las reglas en orden, de la regla de menor número a la más alta, deteniéndose en la primera coincidencia.
3. Grupos de seguridad (SG): aplican reglas directamente a la interfaz de red elástica (ENI) de la instancia EC2. Son con estado, lo que significa que si permite el tráfico entrante, el tráfico de salida de respuesta se permite automáticamente.

Paso 1: Verificación de las tablas de rutas de VPC

La primera verificación de diagnóstico siempre debe confirmar que existe una ruta para que el tráfico llegue siquiera a la subred donde reside la instancia EC2.

Comprobación del enrutamiento de entrada

Para una instancia accesible desde Internet pública (por ejemplo, a través de SSH/RDP):

• Objetivo: Asegurarse de que la subred que contiene la instancia tenga una ruta hacia la Puerta de enlace a Internet (IGW) para el tráfico que se origina en 0.0.0.0/0 (o su rango de IP de cliente específico).
• Acción: Navegue a la consola de VPC, seleccione Tablas de rutas y examine la tabla de rutas asociada con la subred de su instancia. Busque una entrada como:
  Destino: 0.0.0.0/0 | Destino: igw-xxxxxxxx

Comprobación del enrutamiento de salida (para problemas con estado)

Si bien los SG tienen estado, verificar la ruta de salida es crucial, especialmente para el tráfico de respuesta o para las instancias que inician conexiones a servicios externos.

• Acción: Si su instancia se encuentra en una subred privada, asegúrese de que tenga una ruta hacia una Puerta de enlace NAT o Instancia NAT para acceder a Internet. Si se encuentra en una subred pública, debería enrutar 0.0.0.0/0 a la IGW.

Consejo: Si no puede hacer ping a una instancia desde una subred diferente dentro de la misma VPC, el problema es casi con certeza una tabla de rutas mal configurada que dirige el tráfico a la puerta de enlace local incorrecta o a la conexión de emparejamiento de VPC.

Paso 2: Inspección de las Listas de control de acceso a la red (nivel de subred)

Las NACL a menudo se pasan por alto porque operan a nivel de subred y no tienen estado. Un error común es permitir el tráfico entrante pero olvidar permitir explícitamente el tráfico de salida de respuesta.

Verificación de reglas de entrada

Para intentos de conexión de entrada (por ejemplo, SSH en el puerto 22):

1. Identifique la NACL asociada con la subred de la instancia.
2. Examine las Reglas de entrada.
3. Asegúrese de que exista una regla que permita el puerto y protocolo específicos que está utilizando (por ejemplo, Regla 100: Tipo: SSH (22), Protocolo: TCP, Origen: 0.0.0.0/0).

Verificación de reglas de salida (la trampa sin estado)

Aquí es donde ocurren la mayoría de los problemas de conexión de NACL.

1. Examine las Reglas de salida.
2. Si permitió SSH de entrada (Puerto 22), la instancia necesita enviar tráfico de vuelta a su cliente en un rango de puerto alto (puerto efímero), típicamente 1024-65535.
3. Acción: Asegúrese de que una regla de salida permita explícitamente el tráfico al rango de puertos de destino relevante (a menudo 1024-65535 si el cliente inicia la conexión).

Ejemplo de conjunto de reglas NACL para acceso SSH de entrada:

Advertencia: Las NACL evalúan las reglas numéricamente. Si la Regla 90 es DENEGAR TODO, su Regla 100 posterior PERMITIR SSH nunca se alcanzará. Asegúrese de que sus reglas explícitas de PERMITIR tengan números más bajos que cualquier regla amplia de DENEGAR, o confíe en la regla implícita final de DENEGAR TODO.

Paso 3: Auditoría de Grupos de seguridad (nivel de instancia)

Los Grupos de seguridad son la última línea de defensa, aplicados directamente a la instancia. Son más fáciles de administrar porque tienen estado.

Verificación de reglas de entrada

Verifique que el SG adjunto a la instancia EC2 permita el tráfico en los puertos requeridos desde el origen esperado:

• Para SSH (Linux): Regla de entrada que permite TCP Puerto 22 desde su IP pública o 0.0.0.0/0 (si es necesario).
• Para RDP (Windows): Regla de entrada que permite TCP Puerto 3389 desde su IP pública o 0.0.0.0/0.
• Para tráfico web: Regla de entrada que permite TCP Puerto 80 y/o 443 desde 0.0.0.0/0.

Verificación de reglas de salida (generalmente predeterminadas)

Dado que los SG tienen estado, las reglas de salida generalmente se configuran para PERMITIR TODO EL TRÁFICO (0.0.0.0/0 en todos los puertos). Si ha personalizado las reglas de salida, asegúrese de que permitan las respuestas de vuelta al rango de puertos efímeros del cliente.

Mejor práctica: A menos que exista un requisito de seguridad estricto, deje las Reglas de salida del Grupo de seguridad configuradas en el valor predeterminado: Permitir todo el tráfico a todos los destinos. Esto simplifica significativamente la resolución de problemas, ya que puede aislar problemas de NACL o de Tabla de rutas.

Resumen: La lista de verificación del flujo de conectividad

Cuando falla una conexión EC2, siga esta secuencia de diagnóstico:

1. Verificación de la tabla de rutas: ¿Puede la ruta del tráfico (entrante y saliente) alcanzar la puerta de enlace de subred correcta (IGW/emparejamiento de VPC/NAT)?
2. Verificación de NACL (sin estado): ¿Se permite explícitamente el tráfico en el puerto de entrada específico Y se permite explícitamente el tráfico de respuesta (a menudo puertos efímeros altos) de salida?
3. Verificación del grupo de seguridad (con estado): ¿Se permite explícitamente el tráfico en el puerto de entrada específico? (La salida generalmente debería estar abierta).

Al moverse sistemáticamente desde la capa de red general (Enrutamiento) hacia abajo hasta el nivel de subred (NACL) y finalmente hasta el nivel de instancia (SG), puede aislar rápidamente si el mecanismo de bloqueo es filtrado sin estado, filtrado con estado o falla de enrutamiento.