--- title: "Diagnosticar la red en Linux con ping, traceroute y ss" description: "Diagnostica problemas de red en Ubuntu 24.04 paso a paso con ip, ping, dig, traceroute, mtr y ss, y aprende a leer su salida para localizar dónde falla." category: "Configuración de Red" language: es source: https://cubepath.com/es/docs/configuración-de-red/solucion-de-problemas-de-red-con-comandos-ping-traceroute-netstat-ss updated: 2026-09-25 --- # Diagnosticar la red en Linux con ping, traceroute y ss Cuando un servicio "no conecta", el fallo puede estar en la interfaz del servidor, en la puerta de enlace, en el DNS, en algún punto de la ruta, en un firewall o en la propia aplicación. En este tutorial seguirás un método ordenado, de la capa más baja a la más alta, usando `ip`, `ping`, `dig`, `traceroute`, `mtr` y `ss` en Ubuntu 24.04. En cada paso verás qué salida indica que todo va bien y cuál apunta al problema. También verás las equivalencias con `netstat` para quien venga de la herramienta antigua. ## Requisitos previos - Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath. Los comandos funcionan igual en Debian 12; en Rocky Linux 9 cambian los nombres de algunos paquetes (se indican abajo). - Un usuario no root con privilegios `sudo`. - Acceso a la consola del servidor si el problema es precisamente que no llegas por SSH. Como ejemplo, se diagnostica una conexión desde el servidor hacia `example.com` y un servicio web propio en el puerto `443`. ## Paso 1: Instalar las herramientas `ip`, `ss` y `ping` vienen instalados en Ubuntu. Instala el resto: ```bash sudo apt update sudo apt install traceroute mtr-tiny dnsutils netcat-openbsd ``` - `traceroute` y `mtr-tiny` muestran la ruta hasta un destino. `mtr-tiny` es la versión sin interfaz gráfica de `mtr`. - `dnsutils` instala `dig`. - `netcat-openbsd` instala `nc`, para probar si un puerto TCP acepta conexiones. En Rocky Linux 9 el equivalente es `sudo dnf install traceroute mtr bind-utils nmap-ncat`. ## Paso 2: Comprobar la interfaz y la ruta por defecto Antes de mirar fuera, confirma que el servidor tiene la interfaz levantada, una dirección IP y una ruta por defecto. Muestra las interfaces en formato breve: ```bash ip -br addr ``` ```output lo UNKNOWN 127.0.0.1/8 ::1/128 eth0 UP 203.0.113.10/24 2001:db8:10::10/64 fe80::be24:11ff:fe5a:1b2c/64 ``` La interfaz principal debe aparecer como `UP` y con la IP que esperas. Si aparece `DOWN` o sin dirección, el problema está en la configuración de red del propio servidor (en Ubuntu, en los archivos de `/etc/netplan/`). Muestra la tabla de rutas: ```bash ip route ``` ```output default via 203.0.113.1 dev eth0 proto static 203.0.113.0/24 dev eth0 proto kernel scope link src 203.0.113.10 ``` La línea `default via` indica la puerta de enlace. Si falta, el servidor solo puede hablar con su propia subred. Para saber qué interfaz y qué IP de origen se usarán hacia un destino concreto: ```bash ip route get 1.1.1.1 ``` ```output 1.1.1.1 via 203.0.113.1 dev eth0 src 203.0.113.10 uid 1000 ``` ## Paso 3: Probar la conectividad con ping `ping` envía paquetes ICMP echo y mide si vuelven y cuánto tardan. Hazlo en este orden para aislar el fallo: puerta de enlace, una IP pública y luego un nombre. ```bash ping -c 4 203.0.113.1 ping -c 4 1.1.1.1 ping -c 4 example.com ``` Una respuesta sana tiene este aspecto: ```output PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.42 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=1.38 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=1.40 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=1.45 ms --- 1.1.1.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 1.380/1.412/1.450/0.027 ms ``` Cómo interpretar el resultado: | Resultado | Qué significa | |-----------|---------------| | Falla la puerta de enlace | Problema local: interfaz, VLAN, firewall del servidor o de la red. | | Responde la IP pública pero no el nombre (`Temporary failure in name resolution`) | La red funciona y el fallo es DNS. Ve al paso 4. | | `Destination Host Unreachable` | No hay ruta o nadie responde a ARP en la red local. | | Pérdida parcial (`25% packet loss`) | Congestión o un enlace con errores. Usa `mtr` (paso 5). | | `mdev` alto respecto a `avg` | Latencia muy variable (jitter), típico de enlaces saturados. | Prueba también IPv6 si el servidor lo tiene: ```bash ping -6 -c 4 example.com ``` > Nota: que un host no responda a ping no significa que esté caído. Muchos servidores y firewalls filtran ICMP. Confírmalo siempre probando el puerto del servicio (paso 6). Para detectar cortes intermitentes, deja un ping continuo con marca de tiempo (`-D`) y que avise de cada respuesta que no llega (`-O`). Detenlo con `Ctrl+C` para ver el resumen: ```bash ping -D -O 1.1.1.1 ``` ```output [1790238721.402113] 64 bytes from 1.1.1.1: icmp_seq=41 ttl=58 time=1.41 ms [1790238722.403201] no answer yet for icmp_seq=42 ``` La marca de tiempo está en formato Unix; conviértela con `date -d @1790238722` para cruzarla con los logs. ## Paso 4: Comprobar la resolución DNS Si las IP responden pero los nombres no, revisa qué servidores DNS usa el sistema. Ubuntu usa `systemd-resolved`: ```bash resolvectl status ``` ```output Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (eth0) Current Scopes: DNS Current DNS Server: 1.1.1.1 DNS Servers: 1.1.1.1 8.8.8.8 ``` Consulta un nombre con el resolvedor del sistema y después directamente contra un DNS público. Si el segundo funciona y el primero no, el problema está en el DNS configurado en el servidor: ```bash dig +short example.com dig +short example.com @1.1.1.1 ``` ```output 93.184.215.14 ``` Para ver el código de respuesta, quita `+short` y fíjate en la cabecera: ```bash dig example.com ``` ```output ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40125 ``` `NXDOMAIN` significa que el nombre no existe; `SERVFAIL`, que el servidor DNS no pudo resolverlo (a menudo un problema de DNSSEC o del servidor autoritativo); y `connection timed out` indica que no llegas al servidor DNS. ## Paso 5: Seguir la ruta con traceroute y mtr Si hay pérdida o latencia alta hacia un destino, necesitas saber en qué salto empieza. `traceroute` muestra cada router del camino: ```bash traceroute -n example.com ``` ```output traceroute to example.com (93.184.215.14), 30 hops max, 60 byte packets 1 203.0.113.1 0.412 ms 0.388 ms 0.371 ms 2 198.51.100.5 1.102 ms 1.087 ms 1.120 ms 3 * * * 4 192.0.2.33 9.845 ms 9.812 ms 9.901 ms 5 93.184.215.14 10.210 ms 10.198 ms 10.187 ms ``` `-n` evita resolver cada IP a nombre, lo que acelera mucho la salida. Un salto con `* * *` en medio de la ruta es normal: ese router no responde a los paquetes de traceroute pero sí reenvía tráfico, como demuestra que los saltos siguientes responden. Muchos firewalls bloquean los paquetes UDP que usa traceroute por defecto. Para seguir la ruta que realmente toma el tráfico web, usa TCP hacia el puerto del servicio (requiere `sudo`): ```bash sudo traceroute -n -T -p 443 example.com ``` `mtr` combina ping y traceroute y envía paquetes de forma continua, así que da una imagen mucho más fiable de la pérdida por salto. Genera un informe de 100 ciclos: ```bash mtr -rwn -c 100 example.com ``` ```output HOST: server Loss% Snt Last Avg Best Wrst StDev 1.|-- 203.0.113.1 0.0% 100 0.4 0.4 0.3 0.9 0.1 2.|-- 198.51.100.5 0.0% 100 1.1 1.1 1.0 1.6 0.1 3.|-- 192.0.2.17 40.0% 100 8.9 9.1 8.7 12.3 0.5 4.|-- 192.0.2.33 0.0% 100 9.8 9.9 9.7 10.4 0.1 5.|-- 93.184.215.14 0.0% 100 10.2 10.2 10.1 10.6 0.1 ``` La regla para leerlo: **la pérdida solo es real si continúa en los saltos siguientes**. En el ejemplo, el salto 3 muestra un 40 % pero el destino tiene 0 %, así que ese router simplemente limita sus respuestas ICMP. Si la pérdida empezara en un salto y se mantuviera hasta el destino, ese sería el punto problemático, y es el informe que debes adjuntar al abrir una incidencia con tu proveedor. ## Paso 6: Comprobar puertos y conexiones con ss Cuando la red llega pero el servicio no responde, mira qué escucha el servidor. `ss` sustituye a `netstat` y es más rápido. Lista los sockets TCP en escucha con el proceso asociado: ```bash sudo ss -tlnp ``` ```output State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1204,fd=6)) LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1204,fd=7)) LISTEN 0 4096 127.0.0.1:5432 0.0.0.0:* users:(("postgres",pid=987,fd=5)) LISTEN 0 4096 *:22 *:* users:(("sshd",pid=801,fd=3)) ``` Las opciones son `-t` TCP, `-l` en escucha, `-n` sin resolver nombres y `-p` proceso (necesita `sudo` para ver procesos de otros usuarios). Usa `-u` para UDP. Fíjate en la dirección local: `127.0.0.1:5432` solo acepta conexiones desde el propio servidor, así que PostgreSQL no será accesible desde fuera aunque el firewall lo permita. `0.0.0.0` o `*` escuchan en todas las interfaces. Para ver qué proceso ocupa un puerto concreto: ```bash sudo ss -tlnp 'sport = :443' ``` Para listar las conexiones establecidas con un puerto, por ejemplo los clientes conectados al servidor web: ```bash ss -tn state established '( sport = :443 )' ``` Un resumen del número de sockets por estado ayuda a detectar fugas de conexiones o un servicio saturado: ```bash ss -s ``` ```output Total: 312 TCP: 148 (estab 96, closed 31, orphaned 0, timewait 29) ``` Cientos o miles de conexiones en `TIME-WAIT` o `CLOSE-WAIT` apuntan a la aplicación: `CLOSE-WAIT` acumulado significa que el programa no está cerrando los sockets. ### Probar el puerto desde el otro extremo Que un servicio escuche no garantiza que sea alcanzable. Desde otra máquina, prueba el puerto con `nc`: ```bash nc -zv your_server_ip 443 ``` ```output Connection to your_server_ip 443 port [tcp/https] succeeded! ``` - `succeeded`: red, firewall y servicio están bien. - `Connection refused`: llegas al servidor, pero nada escucha en ese puerto (o escucha solo en `127.0.0.1`). - Se queda esperando hasta `timed out`: un firewall descarta los paquetes. Revisa `sudo ufw status` en el servidor y cualquier firewall externo. ## Equivalencias entre netstat y ss `netstat` pertenece al paquete `net-tools`, que ya no se instala por defecto y no recibe desarrollo activo. Si tienes scripts o costumbres antiguas, esta es la traducción: | netstat | ss / ip | Para qué | |---------|---------|----------| | `netstat -tlnp` | `ss -tlnp` | Puertos TCP en escucha con proceso | | `netstat -ulnp` | `ss -ulnp` | Puertos UDP en escucha | | `netstat -tn` | `ss -tn` | Conexiones TCP activas | | `netstat -s` | `nstat -as` | Contadores por protocolo | | `netstat -rn` | `ip route` | Tabla de rutas | | `netstat -i` | `ip -s link` | Estadísticas por interfaz | `ip -s link` merece una mención: si los contadores `errors` o `dropped` de la interfaz crecen, el problema puede estar en el enlace físico o virtual, no en la ruta. ## Solución de problemas **`ping: socket: Operation not permitted`**: ocurre en algunos contenedores sin la capacidad `CAP_NET_RAW`. Ejecútalo en el host o con `sudo`. **`traceroute` solo muestra asteriscos desde el primer salto**: el firewall del servidor bloquea la salida o las respuestas ICMP. Prueba con `sudo traceroute -T -p 443` y revisa las reglas de salida. **`ss -p` no muestra el proceso**: te falta `sudo`; sin privilegios solo ves los procesos de tu usuario. **Todo funciona por IP pero falla por nombre solo en una aplicación**: algunas aplicaciones no usan `systemd-resolved`. Revisa `/etc/resolv.conf` y `/etc/hosts`, y comprueba con `getent hosts example.com`, que usa el mismo mecanismo que la mayoría de programas. ## Conclusión Has seguido un método de diagnóstico por capas: interfaz y rutas con `ip`, alcance con `ping`, nombres con `dig`, la ruta con `traceroute` y `mtr`, y el estado de los servicios con `ss` y `nc`. Siguiendo ese orden normalmente sabes en pocos minutos si el fallo está en el servidor, en el DNS, en la ruta o en la aplicación. Como siguientes pasos puedes: - Medir el ancho de banda real entre dos servidores con `iperf3`. - Capturar tráfico con `tcpdump` cuando necesites ver exactamente qué paquetes entran y salen. - Revisar tu firewall con UFW o nftables si los puertos no son alcanzables desde fuera.