Comandos de red en Linux: ip, ss, ping, traceroute, dig y curl para diagnóstico

Los comandos de red de Linux cubren casi todo el diagnóstico del día a día: ip muestra direcciones y rutas, ss los puertos abiertos y las conexiones, ping y traceroute comprueban si un host responde, dig consulta el DNS y curl revisa la respuesta de un servicio web. A continuación tiene una chuleta con las opciones más útiles y un orden de pasos para buscar la causa cuando «la red no funciona».

Chuleta: comandos de red de Linux en una tabla

ip: direcciones, interfaces y rutas

El comando ip del paquete iproute2 sustituyó a los antiguos ifconfig y route. Los subcomandos se pueden abreviar: ip a = ip addr, ip r = ip route. La opción -br da una salida breve, y -c le pone colores.

$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.1.25/24 fe80::a00:27ff:fe4e:66a1/64
docker0          DOWN           172.17.0.1/16

Si una interfaz no tiene dirección de la red que necesita o está en estado DOWN, no hace falta seguir buscando: el problema está en este nivel.

Cómo añadir una IP y levantar la interfaz

sudo ip link set eth0 up
sudo ip addr add 192.168.1.50/24 dev eth0
sudo ip addr del 192.168.1.50/24 dev eth0

Los cambios hechos con ip duran hasta el reinicio. Para que sean permanentes hay que configurarlos en el sistema: netplan en Ubuntu, NetworkManager (nmcli) en Fedora y RHEL, systemd-networkd en servidores.

Rutas y pasarela por defecto

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.25

$ ip route get 10.20.0.5
10.20.0.5 via 192.168.1.1 dev eth0 src 192.168.1.25 uid 1000

La línea default via indica la pasarela a la que va todo lo que no encaja en rutas más específicas. Si no existe esa línea, no habrá salida a internet aunque la red local funcione. Para añadir una ruta: sudo ip route add 10.20.0.0/16 via 192.168.1.254.

ss: qué puertos están abiertos y quién los escucha

ss sustituyó a netstat y es más rápido. La combinación más habitual es ss -tulpn:

$ sudo ss -tulpn
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=812,fd=6))
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=640,fd=3))
tcp   LISTEN 0      151        127.0.0.1:3306       0.0.0.0:*     users:(("mysqld",pid=901,fd=21))

Fíjese en la dirección: 0.0.0.0 significa que el servicio acepta conexiones por todas las interfaces, y 127.0.0.1, que solo localmente. Esta es una causa frecuente de que una base de datos «no responda» desde otra máquina.

Cómo saber quién ocupa un puerto

sudo ss -ltnp 'sport = :8080'
sudo ss -tn dst 10.0.0.7          # conexiones hacia una dirección concreta
ss -tan state time-wait | wc -l   # cuántos sockets hay en TIME-WAIT

ping: si el host está disponible

ping envía peticiones ICMP echo y muestra el tiempo de respuesta y la pérdida de paquetes. En Linux no se detiene solo, así que indique el número de paquetes con -c.

$ ping -c 4 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.4 ms
...
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.1/12.5/13.0/0.3 ms

Opciones útiles: -i 0.2 — intervalo, -W 2 — tiempo de espera de la respuesta, -4/-6 — versión del protocolo, -s 1472 -M do — comprobar el MTU sin fragmentación. Tenga en cuenta que muchos servidores y nubes bloquean ICMP: que no responda a ping no significa que el host esté caído.

traceroute y mtr: dónde se pierden los paquetes

traceroute muestra los nodos del camino hasta el destino. Los asteriscos en algunos saltos son normales: un router intermedio puede no contestar. La señal preocupante es cuando, a partir de cierto salto, todos los siguientes son asteriscos.

traceroute -n example.com        # sin nombres DNS, más rápido
sudo traceroute -T -p 443 example.com   # TCP en lugar de UDP, atraviesa cortafuegos
tracepath example.com            # sin root, además muestra el MTU

mtr combina ping y traceroute y actualiza en tiempo real las estadísticas de pérdida en cada salto. Para generar un informe: mtr -rwc 50 example.com.

dig: comprobación de DNS

dig, del paquete dnsutils (bind-utils en RHEL), es la herramienta principal para revisar el DNS. La forma corta devuelve solo la respuesta:

$ dig +short example.com
93.184.215.14

$ dig example.com MX +short
$ dig @8.8.8.8 example.com A       # consultar un servidor concreto
$ dig -x 8.8.8.8 +short            # registro inverso (PTR)
$ dig +trace example.com           # recorrer la cadena desde los servidores raíz

En la salida completa mire el campo status: NOERROR — el registro existe, NXDOMAIN — el dominio no existe, SERVFAIL — el servidor no pudo responder (a menudo por DNSSEC o por un servidor autoritativo inaccesible). Si dig @8.8.8.8 responde y el dig normal no, el culpable es el resolutor local: revise /etc/resolv.conf y resolvectl status.

Tenga en cuenta que dig no lee /etc/hosts. Para comprobar la resolución de un nombre tal como la hará una aplicación, use getent hosts example.com.

curl: comprobación de HTTP y de APIs

curl responde a la última pregunta: si el servicio contesta y qué devuelve.

$ curl -s -o /dev/null -w '%{http_code} %{time_connect} %{time_total}\n' https://example.com
200 0.041 0.187

Los mensajes de error de curl indican la capa del fallo: Could not resolve host — DNS, Connection refused — el puerto está cerrado o nadie escucha, Connection timed out — un cortafuegos descarta los paquetes o no hay ruta, SSL certificate problem — problema con el certificado.

Orden de diagnóstico: cuando «no funciona la red»

1. Interfaz y dirección: ip -br addr — la interfaz está UP y tiene dirección.
2. Pasarela: ip route — hay una línea default via; ping -c 3 <pasarela>.
3. Red externa por IP: ping -c 3 1.1.1.1. Si funciona, el enrutamiento está bien.
4. DNS: dig +short example.com. Si está vacío o da error con ping por IP funcionando, el problema está en el resolutor.
5. Puerto: nc -zv host 443 o curl -v. En el servidor, ss -tulpn para ver si el servicio escucha y en qué dirección.
6. Cortafuegos: sudo nft list ruleset, sudo iptables -L -n, sudo ufw status.
7. Aplicación: curl -I y los registros del servicio (journalctl -u nginx).

Avance de abajo arriba y no salte pasos: así en un par de minutos sabrá en qué nivel está el problema, en lugar de reiniciarlo todo sin criterio.

Comandos antiguos y sus sustitutos

En las distribuciones recientes net-tools a menudo ni siquiera está instalado, así que conviene acostumbrarse a los comandos nuevos.

Resumen

Para el diagnóstico diario bastan seis comandos de red de Linux: ip, ss, ping, traceroute, dig y curl. Revise por capas — dirección, ruta, DNS, puerto, aplicación — y el fallo se localiza rápido. Los comandos de red y el análisis de los fallos más comunes se practican en el curso de Linux.