Solución de problemas comunes de conectividad y errores de instancias EC2

Cuando falla una conexión EC2, la primera pregunta útil es si la instancia es inalcanzable, rechaza la autenticación o solo es accesible a través de la ruta incorrecta. Ya sea que esté utilizando SSH para instancias Linux o Protocolo de Escritorio Remoto (RDP) para instancias Windows, los fallos de conectividad son comunes y a menudo frustrantes. Los errores de SSH y RDP tienden a confundirse, pero Permiso denegado, Tiempo de espera agotado, Conexión rechazada y una pantalla RDP en blanco apuntan a diferentes capas. Trate el texto del error como una pista, luego trabaje desde afuera hacia adentro.

Fase 1: Verificaciones iniciales y estado de la instancia

Antes de sumergirse en configuraciones de red complejas, asegúrese de que la instancia se esté ejecutando correctamente y sea accesible a un nivel fundamental.

1. Verificaciones de estado de la instancia

Utilice la Consola de administración de AWS o la CLI de AWS para verificar el estado general de la instancia. Dos verificaciones cruciales deben pasar:

Verificaciones de estado del sistema: Las fallas aquí generalmente indican problemas subyacentes de hardware o infraestructura que requieren intervención de AWS o terminación/recreación de la instancia.
Verificaciones de estado de la instancia: Las fallas aquí a menudo se relacionan con problemas de arranque del sistema operativo, corrupción del sistema de archivos o problemas de controladores. Si esto falla, es probable que la instancia no sea lo suficientemente saludable para aceptar conexiones de red.

Acción: Si alguna de las verificaciones falla, considere detener e iniciar la instancia (lo que la mueve a un nuevo hardware si falla la verificación del sistema) o verifique el registro del sistema en busca de pistas.

2. Verificación de la dirección IP pública y el nombre DNS

Asegúrese de estar intentando conectarse a la dirección correcta. Si su instancia debe ser accesible directamente desde Internet, necesita una Dirección IPv4 pública o una IP elástica y una ruta de subred pública a través de una puerta de enlace de Internet. Si está en una subred privada, debe conectarse a través de un Host Bastión o usar AWS Systems Manager Session Manager.

Consejo: Si la instancia se detuvo y se inició, su dirección IP pública puede haber cambiado a menos que haya asignado una IP elástica.

3. Verificación de la configuración del cliente (SSH/RDP)

Los errores de conectividad a veces son locales. Verifique que su software cliente funcione correctamente.

Para SSH (Linux/macOS): Asegúrese de estar utilizando el archivo de clave privada correcto (.pem o .ppk) y que los permisos estén configurados correctamente (chmod 400 /ruta/a/la/clave.pem).
Para RDP (Windows): Asegúrese de estar utilizando la contraseña correcta obtenida descifrando la contraseña de administrador utilizando el archivo de clave privada en la consola de EC2.

Fase 2: Diagnóstico de capas de seguridad (Los fallos más comunes)

Las configuraciones de seguridad incorrectas son la causa principal de los problemas de conectividad. Tanto los Grupos de seguridad como las ACL de red actúan como cortafuegos, y ambos deben permitir el tráfico necesario.

4. Reglas de entrada del grupo de seguridad (SG)

Los Grupos de seguridad son cortafuegos con estado adjuntos directamente a la Interfaz de red elástica (ENI) de la instancia.

Requisitos de Linux (SSH):

Protocolo: TCP
Rango de puertos: 22
Origen: Su dirección IP pública (Mi IP) o 0.0.0.0/0 (para todas las IP, aunque esto no se recomienda por seguridad).

Requisitos de Windows (RDP):

Protocolo: TCP
Rango de puertos: 3389
Origen: Su dirección IP pública o 0.0.0.0/0.

Paso de solución de problemas: Cambie temporalmente el origen de la regla de entrada requerida a 0.0.0.0/0 para el puerto relevante (22 o 3389). Si puede conectarse, el problema era que su dirección IP de cliente específica estaba bloqueada o no se identificó correctamente.

Advertencia: Nunca deje los grupos de seguridad abiertos a 0.0.0.0/0 para puertos de administración (22/3389) en entornos de producción. Utilice IP de origen específicas o puntos de enlace de VPC cuando sea posible.

5. ACL de red (NACL)

Las ACL de red son cortafuegos sin estado a nivel de subred. Verifican el tráfico entrante y saliente de forma independiente. Si se permite la entrada de tráfico, el tráfico de retorno también debe permitirse la salida.

Requisitos de NACL para la conectividad:

Dirección	Protocolo	Rango de puertos	Acción de regla
Entrante	TCP	22 (SSH) o 3389 (RDP)	Permitir
Saliente	TCP	Puertos efímeros (1024-65535)	Permitir

Los puertos efímeros son críticos. Cuando su cliente se conecta (por ejemplo, desde el puerto 54321), el servidor responde en un puerto efímero de número alto. Si la NACL bloquea el tráfico saliente en estos puertos altos, el servidor no puede enviar la respuesta de vuelta, lo que resulta en un tiempo de espera de conexión.

Paso de solución de problemas: Verifique que tanto el puerto entrante (22/3389) como los puertos efímeros salientes (1024-65535) tengan una regla de Permitir en la NACL asociada.

Fase 3: Enrutamiento y configuración de VPC

Si se confirma que las capas de seguridad están abiertas, el problema radica en cómo se enruta el tráfico hacia y desde la subred de la instancia.

6. Tipo de subred y tablas de enrutamiento

La conectividad depende completamente de si su instancia está en una Subred pública o una Subred privada.

Conectividad de subred pública

Para acceso directo a Internet (SSH/RDP desde el exterior):

A la instancia se le debe asignar una dirección IPv4 pública o IP elástica.
La tabla de enrutamiento asociada debe tener una ruta para 0.0.0.0/0 que apunte a una Puerta de enlace de Internet (IGW).

Conectividad de subred privada

Las instancias en subredes privadas no pueden ser accesibles directamente desde Internet. La conexión requiere una ruta de múltiples saltos:

Conexión a través de un Host Bastión (Jump Box): Usted se conecta por SSH a una instancia EC2 pública, y luego por SSH desde el Host Bastión a la instancia privada (usando su IP privada).
Conexión a través de VPN/Direct Connect: Si utiliza AWS Site-to-Site VPN o Direct Connect, el enrutamiento debe configurarse para dirigir el tráfico a su red local, que luego enruta a la subred privada.

7. Problemas de cortafuegos a nivel de sistema operativo

Si las comprobaciones de seguridad de AWS pasan, el sistema operativo que se ejecuta en la instancia EC2 podría estar bloqueando la conexión. Esto es común si instaló o configuró manualmente cortafuegos locales (como iptables en Linux o el Cortafuegos de Windows Defender).

Diagnóstico (si es posible a través de la Consola o Session Manager):

Linux: Verifique iptables -L o use firewall-cmd --list-all. Asegúrese de que el puerto 22 esté explícitamente permitido.
Windows: Verifique la configuración del Cortafuegos de Windows Defender para las reglas de entrada en el puerto 3389.

Consejo de recuperación: Si ha perdido toda la conectividad, considere detener la instancia, desvincular el volumen raíz, adjuntarlo a una instancia de recuperación en funcionamiento, modificar los archivos de configuración del sistema operativo para deshabilitar el cortafuegos y luego volver a adjuntar el volumen al ID de instancia original.

Opciones de conexión públicas, privadas y gestionadas

No asuma que cada instancia EC2 debe aceptar SSH o RDP desde Internet. Las instancias públicas necesitan una dirección pública, una ruta a una puerta de enlace de Internet, controles de seguridad permisivos y un listener en ejecución. Las instancias privadas generalmente necesitan un método de acceso diferente: un host bastión, VPN, Direct Connect, un Punto de enlace de EC2 Instance Connect o Systems Manager Session Manager.

Session Manager es especialmente útil para los equipos de operaciones porque puede eliminar la necesidad de SSH entrante. La instancia necesita el agente SSM, un perfil de instancia IAM con los permisos correctos de Systems Manager y acceso de red a los puntos de enlace de SSM. En subredes privadas, eso generalmente significa puntos de enlace de interfaz de VPC o Internet saliente a través de una ruta NAT. Si falta alguno de esos componentes, Session Manager no aparecerá como una opción, incluso si la instancia en sí está saludable.

Para un diseño de bastión, pruebe ambas etapas. Primero conéctese desde su estación de trabajo al bastión. Luego conéctese desde el bastión a la IP privada de la instancia de destino. El grupo de seguridad de la instancia de destino generalmente debe permitir SSH solo desde el grupo de seguridad del bastión, no desde su IP doméstica ni desde todo el CIDR de la VPC a menos que tenga una razón.

Para RDP, recuerde que el arranque de Windows puede tardar más que el inicio de SSH en Linux, especialmente después de parches o del primer lanzamiento. Si las comprobaciones de estado de la instancia acaban de pasar pero RDP aún falla, verifique el registro del sistema y espere unos minutos antes de cambiar las reglas del cortafuegos. Reemplazar repetidamente los grupos de seguridad puede ocultar el problema real de arranque o servicio.

Pruebas rápidas desde su estación de trabajo

Utilice pequeñas pruebas de red antes de cambiar los recursos de AWS. Desde Linux o macOS, nc -vz <ip-publica> 22 prueba si el puerto TCP 22 se completa. Para RDP, use nc -vz <ip-publica> 3389 o una herramienta de prueba de puertos desde Windows. Un tiempo de espera apunta a enrutamiento, grupos de seguridad, NACL o un cortafuegos ascendente. Una conexión rechazada apunta más al sistema operativo o servicio de la instancia.

Si DNS está involucrado, resuélvalo explícitamente:

dig +short ec2-203-0-113-10.compute-1.amazonaws.com

Luego compare el resultado con la IP pública actual en la consola de EC2. Las IP elásticas se mantienen estables, pero las IP públicas asignadas automáticamente pueden cambiar después de detener/iniciar. Esta es una causa simple de runbooks rotos y perfiles RDP guardados.

Si usa una VPN corporativa, pruebe desde otra red antes de editar la VPC. Algunas redes de empresa bloquean SSH o RDP saliente, y algunos enrutadores domésticos o ISP interfieren con puertos poco comunes. Una conexión exitosa desde una red diferente le indica que la instancia puede estar bien.

VPC Reachability Analyzer vale la pena usarlo cuando la ruta no es obvia. Puede modelar una ruta entre un origen y un destino y señalar dónde el enrutamiento o el filtrado bloquea el tráfico. No solucionará una clave SSH incorrecta o un servicio detenido dentro del sistema operativo invitado, pero es útil para separar los problemas de diseño de red de AWS de los problemas del sistema operativo.

Los registros de flujo también pueden ayudar, especialmente cuando se sospecha de NACL o grupos de seguridad. Un flujo rechazado desde la IP de su cliente al puerto 22 o 3389 le indica que el paquete llegó a una interfaz de red o subred monitoreada y fue denegado. Ningún flujo en absoluto puede significar que el tráfico nunca llegó a la VPC, la dirección es incorrecta, o está mirando la ENI, subred o ventana de tiempo incorrecta.

Mantenga un pequeño runbook de acceso para cada entorno: rangos de IP de origen aprobados, nombre del bastión, requisitos de SSM, nombres de usuario predeterminados por AMI y el procedimiento de instancia de recuperación. Los incidentes de conectividad se vuelven más lentos cuando cada ingeniero tiene que redescubrir esos detalles desde la consola.

También registre qué subredes son intencionalmente privadas. Esa sola nota evita una gran cantidad de depuración perdida cuando alguien intenta conectarse por SSH directamente a una instancia que nunca fue diseñada para tener una ruta de Internet.

Leyendo el mensaje de error

Tiempo de espera agotado generalmente significa que los paquetes no están completando el viaje. Mire la IP pública, la tabla de enrutamiento, la puerta de enlace de Internet, el origen del grupo de seguridad, las reglas de NACL, el cortafuegos corporativo y si está intentando alcanzar una subred privada directamente.

Conexión rechazada generalmente significa que la ruta de red llegó a la instancia, pero nada está escuchando en ese puerto o el sistema operativo lo rechazó. En Linux, verifique si sshd se está ejecutando y escuchando en el puerto 22. En Windows, verifique si RDP está habilitado y el servicio de Escritorio remoto se está ejecutando.

Permiso denegado (publickey) no es un problema de VPC. Generalmente significa el nombre de usuario incorrecto, la clave privada incorrecta, la clave pública faltante en authorized_keys, permisos de directorio de inicio cambiados, o una discrepancia en el nombre de usuario de AMI como usar ec2-user para una imagen de Ubuntu en lugar de ubuntu.

Para RDP de Windows, los fallos de autenticación a menudo provienen de usar una contraseña de administrador descifrada antigua después de que la instancia fue reemplazada, conectarse a la IP pública incorrecta después de una detención/inicio, o una política de dominio que anula los derechos de inicio de sesión local.

Rutas de recuperación cuando no puede iniciar sesión

Si la instancia tiene el agente de Systems Manager instalado, un perfil de instancia con permisos de SSM y acceso de red a los puntos de enlace de SSM o a Internet, Session Manager suele ser la ruta de recuperación menos disruptiva. Puede inspeccionar registros, corregir reglas de cortafuegos o reparar authorized_keys sin abrir SSH al mundo.

Si SSM no está disponible, use la consola serie de EC2 donde sea compatible, o desvincule el volumen raíz y adjúntelo a una instancia de recuperación en la misma Zona de disponibilidad. Móntelo con cuidado, corrija la configuración de red o SSH, desmóntelo y vuelva a adjuntarlo a la instancia original. Tome una instantánea primero para que un intento de reparación no empeore la recuperación.

Cuando la conectividad falla, siga esta lista de verificación priorizada: estado de la instancia, dirección correcta, nombre de usuario/clave o contraseña RDP correctos, grupo de seguridad, NACL, tabla de enrutamiento, cortafuegos del sistema operativo y estado del servicio. Ese orden evita que cambie cinco controles de AWS cuando el problema real es una clave obsoleta o una ruta faltante.