Saltar a contenido

Metodología de Diagnóstico

Cuando algo no funciona, el error más común es empezar a probar cosas al azar. Funciona a veces, por suerte. Pero en una red compleja o bajo presión, necesitás un método.

El método es simple: ir de abajo hacia arriba. Las capas bajas tienen que funcionar para que las altas puedan funcionar. No tiene sentido revisar el DNS si la interfaz está caída.


El algoritmo

flowchart TD
    A["🔴 Síntoma: algo no funciona"] --> B

    B{"¿La interfaz\nestá UP?"}
    B -->|No| B1["ip link set ethX up\n→ Problema resuelto"]
    B -->|Sí| C

    C{"¿La IP y la máscara\nson correctas?"}
    C -->|No| C1["Corregir con ip addr\n→ Problema resuelto"]
    C -->|Sí| D

    D{"¿Ping al gateway\nfunciona?"}
    D -->|No| D1["Verificar gateway:\nip route show\n→ Corregir ruta default"]
    D -->|Sí| E

    E{"¿Ping por IP\nal destino funciona?"}
    E -->|No| F{"¿traceroute muestra\ndónde muere?"}
    F -->|Muere en router medio| F1["Router intermediario\nsin ruta\n→ Agregar ruta"]
    F -->|No llega ni al primer salto| F2["Problema de ruta\nen este equipo"]
    E -->|Sí, pero sin respuesta| G["Packet Capture:\n¿llegan paquetes\nal destino?"]
    G -->|Llegan pero no vuelven| G1["Falta ruta de vuelta\nen algún router"]

    E -->|Sí| H{"¿Ping por nombre\nfunciona?"}
    H -->|No| H1["Problema de DNS:\ndig + resolv.conf"]
    H -->|Sí| I{"¿El servicio\nresponde?"}
    I -->|No| J{"¿El puerto\nestá abierto?"}
    J -->|No| J1["Firewall bloqueando:\niptables -L\nnmap"]
    J -->|Sí| J2["Servicio caído:\nss -tlnp"]

Las cinco preguntas en orden

Memorizá estas preguntas. Son el checklist que vas a recorrer en cada diagnóstico:

1. ¿Está la interfaz UP?

ip link show

Buscá el estado entre corchetes: <UP,BROADCAST,...> está bien. Si dice <BROADCAST,...> sin el UP, la interfaz está caída.

# Si está caída:
ip link set eth1 up

2. ¿Tengo la IP correcta en la subred correcta?

ip addr show eth1

Verificá: - ¿La IP es la que debería ser? - ¿La máscara (/24, /30) es la misma que la del otro extremo?

Dos hosts con IPs en subredes distintas no se pueden ver aunque estén en el mismo cable.

3. ¿Tengo ruta hacia el destino?

ip route show

Verificá: - ¿Hay una ruta hacia la red destino, o al menos una ruta default? - ¿El gateway de la ruta default existe y responde ping?

ping -c 2 <IP-del-gateway>

Si el gateway no responde, el problema está entre vos y el gateway — no más lejos.

4. ¿Los paquetes llegan a destino?

Si el ping por IP falla, usá traceroute para ver hasta dónde llegan los paquetes:

traceroute <IP-destino>

Si el traceroute se corta en un router del medio (aparecen * * *), ese router es el problema — le falta una ruta.

Si el destino recibe los paquetes pero no responde, usá Packet Capture en el destino para confirmarlo:

tcpdump -i eth1 icmp

Si ves paquetes llegando pero no hay respuesta, el problema es la ruta de vuelta — el destino no sabe cómo responder.

5. ¿El servicio está escuchando y accesible?

Solo llegás acá si el ping por IP funciona pero el servicio no responde.

# ¿Qué puertos están escuchando en el servidor?
ss -tlnp

# ¿Desde el cliente, qué puertos están abiertos?
nmap <IP-servidor>

# ¿Hay reglas de firewall bloqueando?
iptables -L -n -v

Si el puerto no aparece en ss → el servicio no está corriendo.
Si el puerto aparece en ss pero nmap lo muestra filtrado → firewall bloqueando.


Reglas que nunca fallan

Empezá siempre desde abajo. No busques problemas de DNS si la interfaz está caída.

El ping funciona en dos sentidos. Si el ping de A a B falla, puede ser que B no sepa responder — no solo que A no sepa llegar.

Un router solo conoce lo que tiene directamente conectado o lo que le enseñaste. Si falta una ruta estática, el paquete muere ahí silenciosamente.

tcpdump no miente. Si el sniffer dice que el paquete llegó, llegó. Si dice que no llegó, no llegó. Es la fuente de verdad cuando todo lo demás es confuso.