¿Por qué conocer los comandos de red si «ya funciona»?
La red es como la fontanería de una casa: mientras salga agua, nadie piensa en las tuberías. Pero cuando la presión desaparece, de repente hay que sacar la llave inglesa y averiguar dónde está la fuga. En Linux esa llave la forman las utilidades de red de línea de comandos. Ayudan a descubrir por qué «no hace ping», a dónde se fue Internet y si realmente tiene la culpa el proveedor o su iptables mal configurado.
A continuación hay una guía práctica sin aburrimiento ni apuntes de libro. Veremos los comandos clave, ejemplos reales y recopilaremos un conjunto de técnicas útiles para diagnóstico.
El superhéroe con capa: el comando ip
Desde que ifconfig pasó a mejor vida, ip se considera la navaja suiza principal para trabajar con interfaces de red, rutas y reglas. El comando tiene muchas caras: dispone de subcomandos como link, addr, route, rule y una decena más para cualquier situación.
Inspección rápida de interfaces
ip a
El comando muestra la lista de interfaces, sus direcciones IP, MTU y otros detalles. Si hace falta eliminar ruido, añada -s — aparecerán contadores de paquetes, útil al buscar interfaces «aturdidas».
Añadir una dirección estática sin reiniciar
sudo ip addr add 192.168.1.50/24 dev eth0
El sistema aplicará la nueva dirección de inmediato. Para no sorprenderse tras un reinicio, haga el cambio en la configuración de su gestor de red.
Rutas en una sola línea
sudo ip route add 10.10.0.0/16 via 192.168.1.1
Sirve cuando necesita «empujar» tráfico a una subred VPN o a un segmento de pruebas. Para eliminarla basta con cambiar add por del.
- Consejo: la página man es enorme. Use / en el lector para buscar por palabras clave y ahorrarse dolores de cabeza.
El buen y viejo ping: comprobando si un host está vivo
Incluso personas alejadas del TI saben que «hacer ping» significa comprobar la disponibilidad. El comando envía solicitudes ICMP de eco y devuelve estadísticas sobre latencias y pérdidas.
Diagnóstico rápido
ping -c 4 ya.ru
La opción -c limita el número de paquetes. Si algún paquete se pierde en el camino, mire el porcentaje de pérdidas: a veces es culpa del Wi‑Fi y no del «malvado router del proveedor».
Variante de alta velocidad — fping
Cuando necesita explorar toda una subred y encontrar máquinas vivas, fping lo hace más rápido que el ping clásico. Instale el paquete del repositorio y pruebe:
fping -a -g 192.168.1.0/24 2>/dev/null
netstat se va, reciba a ss
netstat fue un símbolo del diagnóstico en Linux desde la era de los dinosaurios, pero hoy sus funciones las ejerce ss. La razón es simple: ss es más rápido, no requiere leer /proc varias veces y es más amigable para scripts.
¿Quién escucha en mis puertos?
sudo ss -tulpn
La opción -p muestra el PID del proceso, y -l muestra solo sockets «escuchando». Si descubre que el puerto 8080 lo ocupa un java desconocido, es hora de preguntar «¿quién lanzó ese Tomcat de prueba en producción?».
Monitorización en tiempo real
sudo watch -n1 'ss -s'
Resulta especialmente útil cuando sospecha una fuga de conexiones: refrescar cada segundo mostrará si el número de TCP ESTAB crece o si todos los vecinos ya cerraron el navegador.
traceroute y mtr: paso a paso
Si un paquete tarda más en llegar al servidor que una pizza en día de lluvia, hay que averiguar dónde se «atasca». traceroute envía una serie de paquetes UDP con TTL creciente, mientras que mtr combina eso con ping, ofreciendo una vista en vivo de la ruta.
traceroute 8.8.8.8
mtr -rw 8.8.8.8
No tema a las asteriscos: solo indican que el salto no responde a ICMP o filtra paquetes. En redes corporativas eso es común.
dig y nslookup: hablar con el servidor DNS en claro
¿La aplicación «no abre», pero el nombre «se resuelve» a un lugar extraño? Compruebe las respuestas DNS manualmente:
dig @8.8.8.8 chat.openai.com +short
Si la respuesta contiene una larga lista de direcciones IP cuando esperaba un par, adivine quién metió la pata en las entradas del CDN. Para una comprobación rápida de un registro sirve nslookup, pero dig ofrece más detalles.
curl y wget: probando HTTP, FTP y otros protocolos
A veces el servidor responde a ping, pero la página no carga; ahí entra curl. Compruebe cabeceras, tiempo de respuesta y TLS en un solo paso:
curl -I -w "
Time: %{time_total}s
" -o /dev/null https://example.com
- Sugerencia: añada -L para que curl siga redirecciones en lugar de dejarlo a medias.
Registros del sistema: dmesg y journalctl
Cuando una interfaz cae de forma inesperada, la causa suele verse en el kernel. dmesg mostrará los eventos recientes de los controladores, y journalctl -u NetworkManager revelará los registros de NetworkManager.
Escenario paso a paso para diagnosticar «se fue Internet»
- Comprobar lo físico. ip link — ¿interfaz DOWN? Ahí está la respuesta.
- ICMP al gateway. ping -c3 192.168.1.1 — si no hay respuesta, revise cable o Wi‑Fi.
- Ruta. ip route — ¿desapareció la ruta por defecto?
- DNS. dig google.com — una respuesta vacía lo dice todo.
- Puertos y servicios. ss -tulpn — busque procesos zombis que bloqueen 53/80/443.
- traceroute a 8.8.8.8. Vea en qué salto se quedan los paquetes.
- dmesg | tail. ¿No habrá salido un error de driver en el kernel?
Preguntas frecuentes y errores comunes
- «ping funciona, pero el navegador no». Lo más probable es que DNS no responda o que TLS falle por fecha/hora incorrectas.
- «Añadí una ruta, pero al reiniciar todo desaparece». Anote los cambios en /etc/network/interfaces o use nmcli, de lo contrario son temporales.
- «netstat muestra todo, ss — nada». Ejecute ss con sudo; sin permisos oculta procesos de otros usuarios.
Enlaces útiles sobre el tema
Conclusión: la ciencia de los pequeños pasos y la gran calma
Dominar las utilidades de red significa dejar de adivinar por qué «simplemente no funciona» y aprender a ver dónde se rompió la ruta, dónde desapareció un paquete o qué socket se quedó «pegado». Elija la herramienta adecuada —ya sea ip o mtr— y practique en servidores de ensayo para que en una situación real ya sepa qué tuerca girar. Que el ping sea estable y el jitter bajo acompañen sus días.
