Diagnóstico de Problemas de Red

Cliente: TechFlow Analytics  ·  Ticket #INC-2026-0618-04  ·  2026-06-18 07:15h
● CRÍTICO Capa 3 / Política
⚙
22:30h
Jun 17
Revisión ACL
✕
07:13h
Jun 18
1er DENY log
✕
07:15h
Jun 18
Incidencia
◎
Ahora
Jun 18
Diagnóstico
Diagnóstico — Causa Raíz
Entrada DENY en ACL INTER-VLAN-ACL bloquea todo el tráfico TCP/UDP de VLAN 30 (10.30.0.0/24) hacia VLAN 50 (10.50.0.0/24), impidiendo la conexión a PostgreSQL en el puerto 5432.
Fallo reportado
Connection timeout 5432
Alcance afectado
VLAN 30 → VLAN 50
Capa OSI
Capa 3 + Política (ACL)
Hosts afectados
app-srv01, app-srv02
Cambio reciente
Revisión ACL ayer 22:30h
Denies ACL
1.247 paquetes
🔍

Síntoma caracterizado

¿Qué falla? Los servidores de aplicaciones no pueden abrir conexiones TCP a 10.50.0.10:5432 (PostgreSQL). Los logs de la app muestran "connection timeout".
¿Quién está afectado? app-srv01 (10.30.0.5) y app-srv02 (10.30.0.6) — todos los hosts en VLAN 30.
¿Cuándo empezó? 07:15h del 2026-06-18. El primer DENY en el log aparece a las 07:13h.
¿Qué cambió? El equipo de seguridad aplicó una revisión de la ACL INTER-VLAN-ACL el 17-Jun a las 22:30h.
📶

Verificación por capas OSI

✓
Capa 1-2 (Física / Enlace) — OK
Vlan30 y Vlan50 están up/up. Sin CRCs, sin errores de trama. Spanning-tree no implicado (SVIs).
✓
Capa 3 (Red) — Rutas OK, conectividad local OK
La ruta connected 10.50.0.0/24 via Vlan50 existe. Ping desde Vlan50 a 10.50.0.10 exitoso (100%). El problema no es de enrutamiento.
✕
Capa 3 (Política / ACL) — FALLO AQUÍ
Ping desde Vlan30 a 10.50.0.10 falla (0%). La ACL INTER-VLAN-ACL aplicada en entrada de Vlan30 tiene una entrada DENY explícita para 10.30.0.0/24 → 10.50.0.0/24 con 1.247 matches.
✓
DNS — No aplica
La aplicación conecta directamente por IP (10.50.0.10). DNS descartado como causa.
📋

Evidencia recopilada

show interfaces vlan 30 / show interfaces vlan 50
Ambas SVIs up/up, sin errores. Descartado problema de interfaz o capa 2.
ping 10.50.0.10 source vlan 30
0% de éxito. Confirma bloqueo desde el gateway de VLAN 30 hacia 10.50.0.10. El tráfico inter-VLAN no llega al destino.
ping 10.50.0.10 source vlan 50
100% de éxito. El servidor PostgreSQL responde correctamente. El host de destino está operativo.
show ip route 10.50.0.0
Ruta connected via Vlan50 presente. Enrutamiento correcto, no hay rutas faltantes ni erróneas.
show ip access-lists INTER-VLAN-ACL
Entrada 30 DENY activa con 1.247 matches. Esta es la entrada bloqueante introducida en la revisión del 17-Jun.
show running-config interface vlan 30
ACL INTER-VLAN-ACL aplicada en dirección IN. Todo el tráfico originado en VLAN 30 pasa por esta política.
show logging | include ACL|DENY|DROP
Logs confirman DENY de tcp 10.30.0.5 → 10.50.0.10:5432 desde las 07:13h. La coincidencia temporal con la ACL modificada es definitiva.
Extracto relevante — ACL INTER-VLAN-ACL
Extended IP access list INTER-VLAN-ACL 10 permit ip 10.10.0.0 0.0.0.255 any (14523 matches) 20 permit ip 10.20.0.0 0.0.0.255 any (9871 matches) 30 deny ip 10.30.0.0 0.0.0.255 10.50.0.0 0.0.0.255 (1247 matches) ← BLOQUEANTE 40 permit ip 10.30.0.0 0.0.0.255 any (55203 matches) 50 deny ip any any log (3 matches)
⚡

Causa raíz

Durante la revisión de la ACL INTER-VLAN-ACL aplicada a la SVI Vlan30 (entrada), se introdujo la entrada 30 DENY ip 10.30.0.0/24 → 10.50.0.0/24 para cumplir una política de segmentación de red. Sin embargo, esta entrada bloquea todo el tráfico inter-VLAN desde VLAN 30 (aplicaciones) hacia VLAN 50 (datos), incluyendo el puerto TCP 5432 de PostgreSQL. La entrada 40 (permit genérico de VLAN 30) nunca se evalúa para el tráfico destino 10.50.0.0/24 porque la entrada 30 coincide primero. El servidor PostgreSQL y la infraestructura subyacente están completamente operativos: la causa es exclusivamente la política ACL.
🔧

Corrección recomendada

1
Insertar una entrada PERMIT específica para PostgreSQL ANTES de la entrada DENY (en ventana de mantenimiento acordada)
ip access-list extended INTER-VLAN-ACL 25 permit tcp 10.30.0.0 0.0.0.255 host 10.50.0.10 eq 5432
La entrada 25 se evalúa antes que la 30. Solo autoriza el puerto 5432 al host exacto, manteniendo la segmentación para el resto del tráfico.
2
Revisar si se necesitan otros puertos de comunicación app → DB (p.ej. backups, monitorización)
! Si se requieren otros puertos, añadir entradas adicionales entre 25 y 30: 26 permit tcp 10.30.0.0 0.0.0.255 host 10.50.0.10 eq 5433 ! pg_replication 27 permit icmp 10.30.0.0 0.0.0.255 10.50.0.0 0.0.0.255 ! monitorización
Confirmar con el equipo de aplicaciones los puertos requeridos antes de aplicar.
3
Documentar el cambio y guardar checkpoint de configuración
copy running-config startup-config archive log config hidekeys
Rollback: eliminar la entrada 25 (y 26/27 si se añadieron) para revertir al estado anterior.
✅

Plan de verificación post-fix

ping 10.50.0.10 source vlan 30
Esperado: 5/5 éxito (100%). Confirma conectividad IP entre SVIs.
show ip access-lists INTER-VLAN-ACL
Esperado: contador de la entrada 25 (permit tcp eq 5432) empieza a incrementar; entrada 30 (deny) deja de sumar matches nuevos del flujo app→db.
show logging | include 10.30.0.5
Esperado: sin nuevos mensajes DENY desde app-srv01 hacia 10.50.0.10:5432 tras el cambio.
Monitorización de la aplicación
Esperado: la aplicación TechFlow establece conexión a PostgreSQL sin timeout; alertas de "connection timeout" cesan.
⚠

Riesgo residual

1. Intención de la segmentación: La entrada DENY fue introducida intencionalmente. Es posible que se requiera confirmación del equipo de seguridad antes de añadir la entrada PERMIT. Verificar con el responsable de seguridad que la excepción para 5432 cumple la política corporativa.

2. Otros flujos VLAN 30 → VLAN 50: Si existen otros servicios que necesiten comunicación entre estas VLANs (backups, monitorización, replicación), también estarán bloqueados. Requiere inventario completo de dependencias antes de cerrar el ticket.

3. Política ACL en otras interfaces: Verificar que no exista una ACL similar aplicada en la SVI Vlan50 en dirección IN o OUT que pudiera bloquear el tráfico de retorno.

4. Cambio controlado: La corrección debe aplicarse en ventana de mantenimiento y con aprobación de cambio (CAB) dado el entorno de producción.
Generado por diagnostico-de-redes · CULTIVA IA — Seguridad Ticket #INC-2026-0618-04 · Analista: Senior Network Agent 2026-06-18 · Modo: solo lectura (sin cambios aplicados)