Solución de Problemas de Red VPC
Introducción
La solución de problemas de red es una habilidad esencial. Esta sección le enseña un método sistemático para diagnosticar problemas de conectividad.
Método de Diagnóstico
┌─────────────────────────────────────────────────────────────┐
│ MÉTODO EN 5 PASOS │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. IDENTIFICAR EL SÍNTOMA │
│ └─► ¿Qué exactamente no funciona? │
│ │
│ 2. VERIFICAR EL CAMINO │
│ └─► ¿Por dónde debe pasar el tráfico? │
│ │
│ 3. PROBAR CADA COMPONENTE │
│ └─► IGW → Route Table → NACL → SG → Instance │
│ │
│ 4. ANALIZAR LOS LOGS │
│ └─► VPC Flow Logs, CloudWatch │
│ │
│ 5. CORREGIR Y VALIDAR │
│ └─► Aplicar la corrección, probar de nuevo │
│ │
└─────────────────────────────────────────────────────────────┘
Checklist de Diagnóstico
Problema: "No puedo acceder a mi instancia desde Internet"
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST ACCESO INTERNET → INSTANCIA │
├─────────────────────────────────────────────────────────────┤
│ │
│ ☐ 1. ¿La instancia tiene una IP pública o Elastic IP? │
│ aws ec2 describe-instances --instance-id i-xxx │
│ → Verificar "PublicIpAddress" │
│ │
│ ☐ 2. ¿El VPC tiene un Internet Gateway adjunto? │
│ aws ec2 describe-internet-gateways │
│ → Verificar "Attachments" → "State: available" │
│ │
│ ☐ 3. ¿La Route Table tiene una ruta hacia el IGW? │
│ aws ec2 describe-route-tables --route-table-id rtb-xxx │
│ → Verificar: 0.0.0.0/0 → igw-xxx │
│ │
│ ☐ 4. ¿El NACL autoriza el tráfico? │
│ aws ec2 describe-network-acls │
│ → Inbound Y Outbound (¡puertos efímeros!) │
│ │
│ ☐ 5. ¿El Security Group autoriza el puerto? │
│ aws ec2 describe-security-groups --group-ids sg-xxx │
│ → Verificar regla inbound para el puerto │
│ │
│ ☐ 6. ¿La instancia está iniciada? │
│ aws ec2 describe-instance-status --instance-id i-xxx │
│ → State: running, Status checks: passed │
│ │
│ ☐ 7. ¿El servicio escucha en el puerto correcto? │
│ (En la instancia) netstat -tlnp | grep :80 │
│ → El servicio debe escuchar en 0.0.0.0:80 │
│ │
└─────────────────────────────────────────────────────────────┘
Problema: "Mi instancia no puede acceder a Internet"
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST INSTANCIA → INTERNET │
├─────────────────────────────────────────────────────────────┤
│ │
│ CASO 1: Instancia en Subnet PÚBLICA │
│ ─────────────────────────────────── │
│ │
│ ☐ ¿La instancia tiene una IP pública? │
│ ☐ ¿Existe ruta 0.0.0.0/0 → igw-xxx? │
│ ☐ ¿SG outbound autoriza el tráfico? │
│ ☐ ¿NACL outbound autoriza? │
│ ☐ ¿NACL inbound autoriza respuestas (puertos efímeros)? │
│ │
│ CASO 2: Instancia en Subnet PRIVADA │
│ ────────────────────────────────── │
│ │
│ ☐ ¿Existe NAT Gateway en subnet pública? │
│ ☐ ¿Existe ruta 0.0.0.0/0 → nat-xxx? │
│ ☐ ¿NAT Gateway está en estado "available"? │
│ ☐ ¿NAT Gateway tiene una Elastic IP? │
│ ☐ ¿SG outbound de la instancia autoriza? │
│ │
└─────────────────────────────────────────────────────────────┘
Problema: "Las instancias en el mismo VPC no se comunican"
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST COMUNICACIÓN INTRA-VPC │
├─────────────────────────────────────────────────────────────┤
│ │
│ ☐ 1. ¿Las instancias están en el mismo VPC? │
│ │
│ ☐ 2. ¿Existe la ruta "local"? (normalmente automática) │
│ 10.0.0.0/16 → local │
│ │
│ ☐ 3. ¿El Security Group ORIGEN autoriza? │
│ Regla inbound: sg-destination o CIDR del subnet │
│ │
│ ☐ 4. ¿El Security Group DESTINO autoriza? │
│ Regla inbound para el puerto y el origen │
│ │
│ ☐ 5. ¿El NACL de ambos subnets autoriza? │
│ (Verificar ambas direcciones) │
│ │
│ ☐ 6. ¿Está usando la IP PRIVADA? │
│ No usar la IP pública para intra-VPC │
│ │
└─────────────────────────────────────────────────────────────┘
Escenarios de Solución de Problemas
Escenario 1: Timeout SSH
┌─────────────────────────────────────────────────────────────┐
│ ESCENARIO: SSH TIMEOUT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Síntoma: ssh -i key.pem ec2-user@52.1.2.3 │
│ Connection timed out │
│ │
│ Diagnóstico: │
│ │
│ 1. Hacer ping a la IP pública │
│ $ ping 52.1.2.3 │
│ → Si timeout: problema antes de la instancia │
│ │
│ 2. Verificar el Security Group │
│ $ aws ec2 describe-security-groups --group-ids sg-xxx │
│ │
│ PROBLEMA ENCONTRADO: │
│ ┌────────────────────────────────────────────┐ │
│ │ Inbound Rules: │ │
│ │ Type: SSH, Port: 22, Source: 10.0.0.0/16 │ │
│ │ │ │
│ │ ❌ ¡Fuente limitada al VPC! │ │
│ │ Su IP pública no está autorizada │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Solución: │
│ $ aws ec2 authorize-security-group-ingress \ │
│ --group-id sg-xxx \ │
│ --protocol tcp --port 22 \ │
│ --cidr SU_IP/32 │
│ │
└─────────────────────────────────────────────────────────────┘
Escenario 2: Sitio Web Inaccesible
┌─────────────────────────────────────────────────────────────┐
│ ESCENARIO: HTTP 502 / TIMEOUT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Síntoma: curl http://52.1.2.3 → timeout │
│ │
│ Diagnóstico: │
│ │
│ 1. Probar puerto desde su máquina │
│ $ nc -zv 52.1.2.3 80 │
│ → Si "Connection refused" = SG OK, servicio KO │
│ → Si "timeout" = SG o ruteo KO │
│ │
│ 2. Verificar Route Table │
│ $ aws ec2 describe-route-tables │
│ │
│ PROBLEMA ENCONTRADO: │
│ ┌────────────────────────────────────────────┐ │
│ │ Routes: │ │
│ │ 10.0.0.0/16 → local │ │
│ │ │ │
│ │ ❌ ¡Sin ruta hacia IGW! │ │
│ │ El subnet es PRIVADO │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Solución: │
│ $ aws ec2 create-route \ │
│ --route-table-id rtb-xxx \ │
│ --destination-cidr-block 0.0.0.0/0 \ │
│ --gateway-id igw-xxx │
│ │
└─────────────────────────────────────────────────────────────┘
Escenario 3: La aplicación no puede acceder a la DB
┌─────────────────────────────────────────────────────────────┐
│ ESCENARIO: APP → DB TIMEOUT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Síntoma: Error de aplicación "Cannot connect to database" │
│ │
│ Configuración: │
│ • App server : 10.0.11.5 (sg-app) │
│ • DB server : 10.0.21.10 (sg-db) │
│ │
│ Diagnóstico: │
│ │
│ 1. Desde App server, probar la conexión │
│ $ nc -zv 10.0.21.10 3306 │
│ → timeout │
│ │
│ 2. Verificar SG de la DB │
│ $ aws ec2 describe-security-groups --group-ids sg-db │
│ │
│ PROBLEMA ENCONTRADO: │
│ ┌────────────────────────────────────────────┐ │
│ │ Inbound Rules: │ │
│ │ Type: MySQL, Port: 3306, Source: sg-web │ │
│ │ │ │
│ │ ❌ ¡sg-app no está autorizado! │ │
│ │ Solo sg-web puede acceder │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Solución: │
│ $ aws ec2 authorize-security-group-ingress \ │
│ --group-id sg-db \ │
│ --protocol tcp --port 3306 \ │
│ --source-group sg-app │
│ │
└─────────────────────────────────────────────────────────────┘
VPC Flow Logs
Activar los Flow Logs
# Crear un log group en CloudWatch
aws logs create-log-group --log-group-name /aws/vpc/flow-logs
# Activar Flow Logs en el VPC
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-xxx \
--traffic-type ALL \
--log-destination-type cloud-watch-logs \
--log-group-name /aws/vpc/flow-logs \
--deliver-logs-permission-arn arn:aws:iam::xxx:role/flow-logs-role
Leer los Flow Logs
┌─────────────────────────────────────────────────────────────┐
│ FORMATO VPC FLOW LOGS │
├─────────────────────────────────────────────────────────────┤
│ │
│ version account-id interface-id srcaddr dstaddr │
│ srcport dstport protocol packets bytes start end │
│ action log-status │
│ │
│ Ejemplo: │
│ 2 123456789012 eni-abc123 10.0.1.5 52.1.2.3 │
│ 54321 443 6 10 5000 1234567890 1234567900 │
│ ACCEPT OK │
│ │
│ Interpretación: │
│ • Origen: 10.0.1.5:54321 │
│ • Destino: 52.1.2.3:443 │
│ • Protocolo: 6 (TCP) │
│ • Acción: ACCEPT (autorizado) │
│ │
│ Acciones posibles: │
│ • ACCEPT: Tráfico autorizado │
│ • REJECT: Tráfico bloqueado por SG o NACL │
│ │
└─────────────────────────────────────────────────────────────┘
Herramientas de Diagnóstico
Comandos Útiles
# Verificar el estado de la instancia
aws ec2 describe-instance-status --instance-id i-xxx
# Verificar el Security Group adjunto
aws ec2 describe-instances --instance-id i-xxx \
--query 'Reservations[].Instances[].SecurityGroups'
# Verificar las reglas de un SG
aws ec2 describe-security-groups --group-ids sg-xxx
# Verificar la Route Table de un subnet
aws ec2 describe-route-tables \
--filters "Name=association.subnet-id,Values=subnet-xxx"
# Verificar el NACL de un subnet
aws ec2 describe-network-acls \
--filters "Name=association.subnet-id,Values=subnet-xxx"
Pruebas Desde la Instancia
# Probar conectividad a Internet
curl -I https://aws.amazon.com
# Probar resolución DNS
nslookup google.com
# Probar puerto específico
nc -zv IP_DESTINATION PORT
# Ver rutas
ip route
# Ver conexiones
netstat -tlnp
ss -tlnp
Tabla de Solución de Problemas Rápida
| Síntoma | Causa Probable | Verificar |
|---|---|---|
| Timeout desde Internet | SG, Route, IGW | Checklist completa |
| Connection refused | Servicio no iniciado | netstat, systemctl |
| Host unreachable | Ruta faltante | Route Table |
| Lento/Intermitente | NACL mal configurado | Reglas NACL |
| Timeout intra-VPC | SG entre instancias | Reglas SG cruzadas |
Resumen
┌─────────────────────────────────────────────────────────────┐
│ RESUMEN SOLUCIÓN DE PROBLEMAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ORDEN DE VERIFICACIÓN: │
│ │
│ 1. Instancia running + status checks OK │
│ 2. IP pública presente (si acceso a Internet) │
│ 3. IGW adjunto al VPC │
│ 4. Ruta 0.0.0.0/0 → igw (subnet público) │
│ 5. NACL autoriza (+ puertos efímeros) │
│ 6. Security Group autoriza │
│ 7. Servicio escucha en el puerto │
│ │
│ HERRAMIENTAS: │
│ • aws ec2 describe-* (estado de los recursos) │
│ • VPC Flow Logs (análisis de tráfico) │
│ • nc, curl, ping (pruebas de conectividad) │
│ │
└─────────────────────────────────────────────────────────────┘
Próxima sección: Lab: Solución de Problemas VPC