Comandos esenciales de red en Linux

En Linux moderno, los comandos esenciales de red provienen de la suite iproute2: ip inspecciona interfaces y rutas, ss lista sockets y puertos en escucha, y ip neigh lee la caché ARP.

Si alguna vez has entrado por shell a un contenedor recién creado, has escrito ifconfig por pura costumbre y te ha devuelto command not found, esta es la razón. La memoria muscular ha sobrevivido a los binarios por una buena década.

Estos reemplazan a los antiguos binarios de net-tools (ifconfig, route, netstat, arp), que Red Hat incluye entre los comandos que deberías dejar de usar y que a menudo no están instalados en absoluto en las distribuciones actuales. Esta referencia agrupa los comandos según la tarea que estés realizando (comprobar interfaces, enrutamiento, conectividad, DNS, puertos y tráfico) y cierra con un flujo de resolución de problemas que va del síntoma al comando y que puedes seguir de principio a fin.

¿Qué reemplazó a ifconfig, netstat y route en Linux?

net-tools ha sido considerado obsoleto desde principios de los años 2000, con iproute2 como el reemplazo en desarrollo activo. El paquete net-tools-deprecated de openSUSE documenta la correspondencia canónica uno a uno:

Opta por la forma de iproute2. En un contenedor mínimo o un servidor recién instalado, los binarios legados pueden no existir, por lo que los scripts que invocan ifconfig o netstat fallan con command not found.

Interfaces y direcciones

ip addr (o el alias ip a) muestra cada interfaz y sus direcciones IPv4/IPv6 asignadas, el equivalente moderno de ifconfig. Usa ip link para levantar o apagar una interfaz, y hostname -I para imprimir únicamente las direcciones IP de la máquina.

ip addr                       # all interfaces + addresses (alias: ip a)
ip addr show eth0             # one interface only
sudo ip link set eth0 down    # take an interface offline
sudo ip link set eth0 up      # bring it back online
hostname -I                   # print all IP addresses, space-separated

Un único binario, ip, cubre direcciones, interfaces, enrutamiento y túneles. hostname -I es la forma más rápida de obtener una dirección para un script sin tener que parsear la salida de ip addr.

Enrutamiento

ip route muestra y edita la tabla de enrutamiento del kernel, reemplazando al comando legado route. Ejecútalo sin argumentos para ver hacia dónde va el tráfico y cuál es la puerta de enlace predeterminada.

ip route                                      # view the routing table
ip route get 1.1.1.1                          # show which route a destination uses
sudo ip route add 10.0.0.0/24 via 192.168.1.1 # add a static route

ip route get es la forma rápida de responder a la pregunta «¿qué interfaz y qué puerta de enlace usará este destino?». Resulta útil cuando un host es alcanzable desde una red pero no desde otra.

Conectividad y ruta

ping comprueba si un host responde; traceroute y mtr muestran por dónde viajan los paquetes y dónde mueren. Limita siempre ping con un contador: ping -c 5 example.com envía cinco paquetes y termina, en lugar de ejecutarse indefinidamente.

ping -c 5 example.com     # send 5 ICMP echoes, then stop
traceroute example.com    # trace the hop-by-hop path
sudo traceroute -T -p 443 example.com  # trace using TCP to port 443
mtr example.com           # live ping + traceroute in one view

Si no se le indica lo contrario, traceroute se rinde tras 30 saltos y dimensiona cada sonda en 60 bytes sobre IPv4 y 80 bytes sobre IPv6. Añadir -T sustituye las sondas UDP predeterminadas por sondas TCP, que atraviesan cortafuegos que descartan las predeterminadas. mtr example.com combina ping y traceroute en una única vista en vivo, de modo que puedes observar la pérdida de paquetes por salto actualizándose en tiempo real. Ten en cuenta que traceroute y mtr a menudo no vienen preinstalados: añádelos con sudo apt install mtr traceroute (Debian/Ubuntu) o sudo dnf install mtr traceroute (RHEL/Fedora).

Consultas DNS

dig es la herramienta principal para consultas DNS; +short recorta la salida a la respuesta, -x realiza una búsqueda inversa y @server apunta a un resolver específico. nslookup y host cubren el mismo terreno de forma más concisa.

dig +short example.com            # just the resolved A record(s)
dig -x 8.8.8.8                    # reverse lookup: IP -> hostname
dig +short example.com @8.8.8.8   # query Google's public resolver directly
host example.com                  # terse forward/reverse lookup
nslookup example.com              # interactive-capable lookup

Consultar un resolver de forma explícita es el paso clave de aislamiento: para distinguir un fallo de DNS de un resolver local defectuoso, ejecuta dig +short example.com @8.8.8.8; si eso resuelve pero tu resolver predeterminado no, el problema es tu resolver, no el dominio.

¿Cómo averiguar qué está usando un puerto en Linux?

Para averiguar qué proceso está ocupando un puerto, ejecuta ss -tulnp | grep :8080. El flag -p imprime el PID y el nombre del proceso propietario del socket. Esta es la solución al error «port already in use» cuando un servidor o un contenedor no consigue hacer bind.

ss -tlnp                    # all listening TCP sockets + owning process
ss -tulnp | grep :8080      # what's bound to port 8080 (TCP + UDP)

Los flags se leen así: t=TCP, u=UDP, l=en escucha (listening), n=numérico (sin resolución de nombres), p=proceso. Ver el nombre del proceso de sockets que no te pertenecen requiere root, así que añade el prefijo sudo. ss es el reemplazo moderno de netstat, y la propia página de manual de netstat califica el comando de mayormente obsoleto y te remite al ss basado en netlink cuando un servidor con mucha carga tiene muchos sockets que listar. De ahí viene la diferencia de velocidad: ss pregunta al kernel mediante netlink, mientras que netstat lee archivos de texto bajo /proc/net. Una vez que tengas el PID, deténlo con kill <pid>.

Tráfico y transferencia

tcpdump captura paquetes en vivo, mientras que curl, wget y nc comprueban la accesibilidad y transfieren archivos. Usa tcpdump para ver exactamente qué circula por el cable cuando las herramientas de más alto nivel no dan respuesta.

sudo tcpdump -i eth0 port 80    # capture HTTP traffic on eth0
curl -v https://example.com     # verbose HTTP request, headers and TLS
wget -O out.html https://example.com  # download to a file
nc -zv example.com 443          # check if a port is open (no data sent)

Extraer paquetes de una interfaz con tcpdump requiere privilegios elevados, lo que en la práctica significa ejecutarlo con sudo (o conceder al binario la capacidad CAP_NET_RAW). nc -zv host puerto es la comprobación de puerto de una sola línea más rápida: -z escanea sin enviar datos y -v informa del resultado. En Docker Desktop, host.docker.internal se resuelve por sí solo, así que nc -zv host.docker.internal 8080 alcanza el host desde dentro de un contenedor. En Docker Engine para Linux tienes que mapearlo tú mismo, arrancando el contenedor con --add-host=host.docker.internal:host-gateway (compatible desde Docker Engine 20.10).

Flujo de resolución de problemas: del síntoma al comando

Asocia el síntoma a una ruta de decisión y avanza hacia fuera partiendo de tu máquina.

• Host inalcanzable → ping -c 5 host para comprobar la accesibilidad, después traceroute host o mtr host para localizar dónde mueren los paquetes, y luego ip route para confirmar que tienes una ruta y una puerta de enlace válidas.
• «Port already in use» → ss -tulnp | grep :<puerto> para encontrar el PID propietario, y después kill <pid> o hacer bind en otro puerto.
• Fallo de DNS → dig +short example.com contra tu resolver, y después dig +short example.com @8.8.8.8 contra uno público; si solo resuelve la consulta pública, la culpa es de tu resolver local.
• Enlace lento o saturado → sudo iftop o bmon para ver el ancho de banda por conexión en tiempo real (instálalos con sudo apt install iftop bmon).

Cada comando de estas cadenas confirma o descarta una capa (enlace, ruta, resolución de nombres, socket), de modo que acotas el fallo en lugar de adivinar.

Recurre primero a las herramientas de iproute2 (ip, ss, ip neigh), acude a net-tools solo en sistemas que todavía lo incluyan, y sigue las rutas de síntoma a comando anteriores la próxima vez que falle un bind o un host quede a oscuras.

Preguntas frecuentes

¿Cuál es la diferencia entre ss y netstat, y son intercambiables?

No son intercambiables. ss es el reemplazo moderno, y la propia página de manual de netstat describe el comando como mayormente obsoleto y remite a ss en su lugar. ss solicita los datos de sockets al kernel mediante netlink, mientras que netstat lee archivos de texto bajo /proc/net, razón por la cual ss se comporta mejor en servidores con muchos sockets. Ambos listan conexiones y puertos en escucha, pero los scripts deberían invocar ss porque netstat puede no estar instalado.

¿Cómo encuentro y termino el proceso que usa un puerto concreto en Linux?

Ejecuta ss -tulnp | grep :8080 para encontrar el socket asociado a ese puerto; el flag -p imprime el PID y el nombre del proceso propietario. Ver los nombres de proceso de sockets que no te pertenecen requiere root, así que añade el prefijo sudo. Una vez que tengas el PID, deténlo con kill seguido del PID. Esto resuelve el error 'port already in use' cuando un servidor o un contenedor no consigue hacer bind.

¿Por qué ifconfig devuelve command not found en mi servidor?

Porque ifconfig pertenece al paquete net-tools, que muchas distribuciones modernas ya no instalan por defecto. Red Hat incluye ifconfig y route entre los comandos que iproute2 reemplaza, RHEL ha omitido net-tools en su instalación predeterminada desde la versión 7, y Debian ha hecho lo mismo desde Debian 9. Usa ip addr en su lugar para ver interfaces y direcciones, o instala net-tools manualmente si algún script legado requiere el binario antiguo.

¿Cómo puedo saber si un problema de DNS es del dominio o de mi resolver local?

Consulta un resolver público directamente con dig +short example.com @8.8.8.8 y compáralo con dig +short example.com usando tu resolver predeterminado. Si la consulta pública resuelve pero la predeterminada no, la culpa es de tu resolver local, no del dominio. La sintaxis @server fuerza a dig a omitir el resolver configurado, aislando el fallo en un solo lado sin modificar ninguna configuración del sistema.

¿Por qué traceroute o mtr no están instalados en mi sistema?

traceroute, mtr, whois, nmap e iftop a menudo no se incluyen en las instalaciones mínimas o predeterminadas, por lo que devuelven command not found. Instálalos con sudo apt install mtr traceroute en Debian y Ubuntu, o con sudo dnf install mtr traceroute en RHEL y Fedora. A diferencia de ip y ss, que vienen incluidos con iproute2 por defecto, estas herramientas de trazado de rutas y escaneo suelen tener que añadirse mediante el gestor de paquetes.