Herramientas de diagnóstico de red en Linux: guía práctica

herramientas-diagnostico-de-red
herramientas-diagnostico-de-red

Las herramientas de diagnóstico de red en Linux son fundamentales para comprobar el estado de una conexión, detectar errores y solucionar problemas de comunicación entre equipos. Gracias a ellas, podemos verificar si hay conectividad, revisar rutas, analizar DNS, comprobar puertos abiertos o identificar qué servicios están escuchando en el sistema.

En este artículo veremos las herramientas de diagnóstico de red más utilizadas en Linux, como ping, ip, traceroute, ss, dig, nslookup o curl. El objetivo es aprender a usarlas de forma práctica para detectar fallos comunes y entender mejor el comportamiento de la red desde la terminal.

👉 Y recuerda, si quieres aprender más de Linux, pincha en este curso de Linux gratis

👉 También te dejo por aquí una guía de comandos Linux por categorías

Qué comprobar en 30 segundos

  1. ¿La interfaz está arriba y con IP? (ip a)
  2. ¿Hay ruta por defecto? (ip r)
  3. ¿Resuelve DNS? (dig)
  4. ¿Llega a un IP externo? (ping a una IP pública o al gateway)
  5. ¿El puerto del servicio responde? (ss, nc, curl)

Si algo falla aquí, normalmente ya tienes el “bloque” culpable y puedes bajar al apartado correspondiente.

ip: interfaz, IP, rutas

ip es el multi-herramienta base para ver estado de red: interfaces, direcciones, rutas..

Ver interfaces e IPs

ip -br a
ip a show dev eth0

Cómo interpretar:

  • UP/DOWN indica estado administrativo; LOWER_UP indica link físico activo.
  • Revisa si la IP (inet) y la máscara son correctas.
  • Si solo ves inet6 y no inet, puede que no tengas IPv4 (o DHCP no asignó).

Ver rutas (incluida ruta por defecto)

ip r
ip r get 1.1.1.1

Cómo interpretar:

  • Debe existir una default via <gateway> dev <iface>.
  • ip r get muestra por qué interfaz saldría el tráfico y qué IP origen usaría.

ss: sockets, puertos en escucha y conexiones

Sustituye a netstat en la mayoría de casos. Es ideal para confirmar si un servicio escucha y desde dónde.

🔗 Más info: ss(8) — man7.org.

Puertos en escucha

ss -lntup

Cómo interpretar:

  • Si un servicio debe escuchar en 0.0.0.0:PUERTO pero aparece en 127.0.0.1:PUERTO, solo acepta conexiones locales.
  • Si aparece en [::]:PUERTO, está escuchando en IPv6 (y a veces también en IPv4, según configuración del sistema).

Conexiones activas (útil para ver SYNs/reintentos)

ss -nt state established
ss -nt state syn-sent,syn-recv

Cómo interpretar:

  • Muchas en SYN-SENT pueden indicar bloqueo en red/firewall, ruta rota o puerto cerrado/filtrado.

ping: conectividad y latencia

Sirve para comprobar alcance y latencia básica.

Ojo: ICMP puede estar filtrado, así que “no responde” no siempre significa “no hay red”.

🔗 Más info: ping(8) — man7.org.

ping -c 4 192.168.1.1        # gateway
ping -c 4 1.1.1.1            # salida a Internet sin DNS
ping -c 4 example.com        # prueba de DNS + conectividad

Cómo interpretar:

  • time=… ms estable y bajo: ruta sana.
  • Pérdida alta: Wi‑Fi débil, congestión, errores físicos o QoS.
  • Destination Host Unreachable: suele ser problema de rutas/ARP o gateway caído.

mtr // traceroute: ruta y saltos problemáticos

traceroute muestra la ruta; mtr combina traceroute + estadísticas (muy útil para diagnóstico).

🔗 Más info: traceroute(8) — man7.org y mtr — bitwizard.nl.

Con mtr (recomendado)

mtr -rwzc 50 1.1.1.1

Cómo interpretar:

  • Mira Loss% y latencia por salto. Pérdida en saltos intermedios con 0% en el destino suele ser depriorización/rate limit de ICMP en routers, no un problema real de datos.

Con traceroute

traceroute -n 1.1.1.1
traceroute -n -T -p 443 example.com

Cómo interpretar:

  • * * * en un salto: no respondió (filtrado o rate limit).
  • -T -p 443 usa TCP y ayuda cuando ICMP/UDP está filtrado.

dig // nslookup : DNS

DNS es origen de muchos “no conecta” que en realidad son “no resuelve”.

🔗 Más info: dig(1) — manpages.debian.org.

dig example.com
dig +short example.com
dig @1.1.1.1 example.com
dig +trace example.com

Cómo interpretar:

  • status: NOERROR con ANSWER SECTION: resolución correcta.
  • SERVFAIL: fallo del resolver upstream, DNSSEC, timeouts o interceptación.
  • NXDOMAIN: el nombre no existe (ojo con typos).
  • Query time: si es alto, puede haber latencia o pérdida hacia el DNS configurado.

curl: HTTP/HTTPS, cabeceras, redirecciones

Ideal para probar servicios web, cabeceras, redirecciones y medir en qué fase se está yendo el tiempo.

🔗 Docs: curl.se — documentación.

Ver solo cabeceras y seguir redirects

curl -I -L https://example.com

Ver tiempos (DNS, conexión, TLS, primer byte)

curl -sS -o /dev/null -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://example.com

Cómo interpretar:

  • Si dns es alto: problema de DNS.
  • Si connect es alto o falla: rutas/firewall/puerto.
  • Si tls falla: certificados, SNI, inspección TLS o hora del sistema.
  • Si ttfb es alto pero connect/tls están bien: el servicio responde lento (backend).

tcpdump: captura de paquetes

Cuando los síntomas no cuadran, captura tráfico en la interfaz correcta. Aquí no “opinamos”: vemos qué sale y qué entra.

🔗 Más info: tcpdump(1) — tcpdump.org.

Capturar ping

sudo tcpdump -ni eth0 icmp

Cómo interpretar:

  • Si ves echo request saliendo pero no echo reply entrando: el problema está “fuera” (ruta/filtrado destino).
  • Si no ves ni request: la app no está enviando por esa interfaz, o estás capturando en la interfaz equivocada.

Capturar tráfico a un puerto

sudo tcpdump -ni eth0 host 203.0.113.10 and port 443

Cómo interpretar:

  • Patrón típico de bloqueo: ves SYN saliendo repetido y nunca SYN/ACK de vuelta.
  • Si ves SYN/ACK y tu host responde con RST, puede ser firewall local o el proceso no escucha en ese puerto.

Consejo: para análisis posterior, guarda un pcap:

sudo tcpdump -ni eth0 -w captura.pcap host 203.0.113.10 and port 443

nmap: escaneo de puertos y descubrimiento

Útil para confirmar si un host expone puertos o si están filtrados. Respeta políticas de tu organización: escanear redes ajenas puede ser inapropiado o ilegal.

🔗 Docs: Nmap Reference Guide — nmap.org.

nmap -Pn -p 22,80,443 203.0.113.10
nmap -sS -sV -p 1-1024 203.0.113.10

Cómo interpretar:

  • open: el puerto responde y hay servicio.
  • closed: el host responde, pero no hay servicio en ese puerto.
  • filtered: no hay respuesta (firewall/ACL) o se bloquea el tráfico.

ethtool: link, velocidad, dúplex y errores

Si hay cortes, pérdida o rendimiento raro en cableado, revisa el link.

🔗 Más info: ethtool(8) — man7.org.

sudo ethtool eth0
sudo ethtool -S eth0 | head

Cómo interpretar:

  • Speed/Duplex: valores inesperados (p. ej. 100Mb half) sugieren auto-negociación fallida o cable defectuoso.
  • Contadores con errores (CRC, drops) apuntan a problemas físicos, driver o negociación.

nc (netcat): probar puertos TCP/UDP

Cuando no hay un protocolo “alto nivel” (o no quieres usarlo), prueba el puerto a nivel TCP/UDP.

🔗 Más info: nc(1) — man7.org.

TCP

nc -vz 203.0.113.10 443
nc -vz -w 3 203.0.113.10 22

Cómo interpretar:

  • succeeded: el puerto acepta conexión (al menos a nivel TCP).
  • timed out: filtrado o ruta rota.
  • refused: host alcanzable, puerto cerrado o servicio caído.

Checklist final (para cerrar el diagnóstico)

  • Interfaz UP y con IP correcta (ip -br a).
  • Ruta por defecto y ruta al destino (ip r, ip r get <destino>).
  • Gateway accesible (ping <gateway>) y salida a Internet por IP (ping 1.1.1.1).
  • DNS resuelve rápido y sin errores (dig, dig @<dns>).
  • Servicio local escucha donde debe (ss -lntup).
  • Puerto remoto responde (o está filtrado) (nc, nmap).
  • Ruta y pérdida por saltos razonables (mtr o traceroute).
  • Si hay dudas: evidencia en paquetes (tcpdump).
  • En cable: link/velocidad/errores correctos (ethtool).

Conocer las herramientas de diagnóstico de red en Linux permite resolver problemas de conectividad de manera más rápida y precisa. Comandos como ping, ip route, ss, traceroute o dig ayudan a comprobar si una red funciona correctamente, si el DNS responde, si existen rutas válidas o si un puerto está disponible.

Dominar estas herramientas es muy útil tanto para usuarios de escritorio como para administradores de sistemas, técnicos de soporte, estudiantes de redes y profesionales de ciberseguridad. Una buena base en diagnóstico de red facilita la administración de servidores, mejora la resolución de incidencias y permite trabajar con mayor seguridad en entornos Linux.

Comentarios

No hay comentarios aún. ¿Por qué no comienzas el debate?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *