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:
sudo apt update
sudo apt install traceroute mtr-tiny dnsutils netcat-openbsd
tracerouteymtr-tinymuestran la ruta hasta un destino.mtr-tinyes la versión sin interfaz gráfica demtr.dnsutilsinstaladig.netcat-openbsdinstalanc, 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:
ip -br addr
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:
ip route
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:
ip route get 1.1.1.1
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.
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:
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:
ping -6 -c 4 example.com
Notaque 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:
ping -D -O 1.1.1.1
[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:
resolvectl status
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:
dig +short example.com
dig +short example.com @1.1.1.1
93.184.215.14
Para ver el código de respuesta, quita +short y fíjate en la cabecera:
dig example.com
;; ->>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:
traceroute -n example.com
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):
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:
mtr -rwn -c 100 example.com
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:
sudo ss -tlnp
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:
sudo ss -tlnp 'sport = :443'
Para listar las conexiones establecidas con un puerto, por ejemplo los clientes conectados al servidor web:
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:
ss -s
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:
nc -zv your_server_ip 443
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 en127.0.0.1).- Se queda esperando hasta
timed out: un firewall descarta los paquetes. Revisasudo ufw statusen 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
tcpdumpcuando necesites ver exactamente qué paquetes entran y salen. - Revisar tu firewall con UFW o nftables si los puertos no son alcanzables desde fuera.