Diagnóstico de Problemas de Conectividad de Instancias EC2: Grupos de Seguridad y ACL de Red

Cuando su instancia EC2 está en ejecución pero SSH, RDP o el tráfico de aplicaciones se agota, el problema suele estar en la ruta de red alrededor de la instancia. Diagnostique la conectividad de EC2 verificando primero la tabla de enrutamiento, luego la ACL de red de la subred y luego el grupo de seguridad de la instancia.

Comprender la jerarquía y 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 incorrectas en cualquiera de estos componentes, o rutas de enrutamiento incorrectas, bloquearán inmediatamente el tráfico esperado, lo que provocará tiempos de espera de conexión frustrantes.

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 de tráfico hacia su instancia EC2:

Tablas de Enrutamiento: Determinan hacia dónde se dirige el tráfico de red según la dirección IP de destino. Si el tráfico destinado a Internet o a la IP de su cliente no puede llegar a la puerta de enlace de subred correcta, la conectividad fallará.
ACL de Red (NACL): Aplican reglas a una subred completa. Son sin estado, lo que significa que tanto el tráfico entrante como el saliente deben permitirse explícitamente. Procesan las reglas en orden, desde la regla con el número más bajo hasta la más alta, deteniéndose en la primera coincidencia.
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 saliente de retorno se permite automáticamente.

Paso 1: Verificar las Tablas de Enrutamiento de la VPC

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

Verificación del Enrutamiento Entrante

Para una instancia accesible desde Internet público (por ejemplo, mediante SSH/RDP):

Objetivo: Asegurarse de que la subred que contiene una instancia pública tenga una ruta predeterminada a una Puerta de Enlace de Internet (IGW).
Acción: Navegue a la consola de VPC, seleccione Tablas de Enrutamiento y examine la tabla de enrutamiento asociada con la subred de su instancia. Busque una entrada como:
```
Destino: 0.0.0.0/0 | Destino: igw-xxxxxxxx
```

Verificación del Enrutamiento Saliente (Para Problemas con Estado)

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

Acción: Si su instancia está en una subred privada, asegúrese de que tenga una ruta a una Puerta de Enlace NAT o Instancia NAT para llegar a Internet. Si está en una subred pública, debe enrutar 0.0.0.0/0 a la IGW.

Consejo: El tráfico entre subredes en la misma VPC normalmente usa la ruta local implícita. Si ese tráfico falla, verifique los grupos de seguridad, las NACL, los firewalls del host y si el destino permite ICMP antes de culpar a la tabla de enrutamiento.

Paso 2: Inspeccionar las ACL de Red (Nivel de Subred)

Las NACL a menudo se pasan por alto porque operan a nivel de subred y son sin estado. Un error común es permitir el tráfico entrante pero olvidarse de permitir explícitamente el tráfico saliente de retorno.

Verificación de Reglas Entrantes

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

Identifique la NACL asociada con la subred de la instancia.
Examine las Reglas Entrantes.
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, Fuente: 0.0.0.0/0).

Verificación de Reglas Salientes (La Trampa Sin Estado)

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

Examine las Reglas Salientes.
Si permitió SSH entrante (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.
Acción: Asegúrese de que una regla saliente permita explícitamente el tráfico al rango de puertos de destino relevante (a menudo 1024-65535 si el cliente está iniciando la conexión).

Ejemplo de Reglas NACL para Acceso SSH Entrante:

Reglas entrantes:

N.º de Regla	Tipo	Protocolo	Rango de Puertos	Fuente	Permitir/Denegar
100	SSH	TCP	22	IP de su cliente/CIDR	PERMITIR
*	*	*	*	*	DENEGAR (Predeterminado)

Reglas salientes:

N.º de Regla	Tipo	Protocolo	Rango de Puertos	Destino	Permitir/Denegar
100	TCP personalizado	TCP	1024-65535	IP de su cliente/CIDR	PERMITIR
*	*	*	*	*	DENEGAR (Predeterminado)

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 PERMITIR tengan números más bajos que cualquier regla DENEGAR amplia, o confíe en la regla DENEGAR TODO implícita final.

Paso 3: Auditar los 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 son con estado.

Verificación de Reglas Entrantes

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

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

Verificación de Reglas Salientes (Generalmente por Defecto)

Dado que los SG tienen estado, las reglas salientes generalmente se configuran para PERMITIR TODO el Tráfico (0.0.0.0/0 en todos los puertos). Si ha personalizado las reglas salientes, asegúrese de que permitan 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 Salientes del Grupo de Seguridad configuradas como 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 Tabla de Enrutamiento.

Lista de Verificación de Conectividad

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

Verificación de Tabla de Enrutamiento: ¿Puede la ruta de tráfico (entrante y saliente) llegar a la puerta de enlace de subred correcta (IGW/Enlace de VPC/NAT)?
Verificación de NACL (Sin Estado): ¿Está el tráfico explícitamente PERMITIDO en el puerto entrante específico Y está el tráfico de retorno (a menudo puertos efímeros altos) explícitamente PERMITIDO saliente?
Verificación de Grupo de Seguridad (Con Estado): ¿Está el tráfico explícitamente PERMITIDO en el puerto entrante específico? (El saliente generalmente debe estar abierto).

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