Uno de los primeros comandos de red que aprendí en Linux fue ping 8.8.8.8. Es una prueba rápida, simple y muy útil para comprobar si existe conectividad básica. Sin embargo, con el tiempo entendí que quedarse solo en el ping es quedarse muy corto cuando un problema de red empieza a tener varias capas.

Hoy sigo usándolo como punto de partida, pero no como diagnóstico completo. Cuando algo deja de responder como debería, lo que realmente funciona es encadenar varias comprobaciones para ir acotando el origen del fallo.

Por qué un ping no basta

Un ping puede decirte si hay respuesta o no, pero no siempre explica por qué. Puede fallar por un problema local, por una mala ruta, por una configuración errónea de la interfaz, por DNS o por un salto intermedio que está rompiendo el tráfico.

Por eso, en lugar de tratar el ping como una respuesta final, prefiero verlo como el inicio de un proceso de diagnóstico más ordenado.

El orden que suelo seguir en Linux

1. Ping

Lo primero que compruebo es si el equipo puede alcanzar una IP conocida, por ejemplo 8.8.8.8, o directamente la puerta de enlace de la red local.

• Si no responde ni el router ni una IP externa, suelo pensar antes en un problema local o de conectividad básica.
• Si responde a IP pero no a nombres de dominio, la sospecha se desplaza hacia DNS.

Es una prueba sencilla, pero útil para separar muy rápido conectividad básica y resolución de nombres.

2. ip a

Después reviso el estado de la interfaz. Con ip a puedo comprobar si la tarjeta tiene dirección IP, si la interfaz está en estado UP y si la configuración parece coherente.

Cuando aquí ya se ve algo raro —una interfaz caída, sin IP o con una configuración incompleta— muchas veces ni siquiera hace falta seguir avanzando: el problema ya está bastante acotado.

3. ip route

Si la interfaz está bien, el siguiente paso es mirar la tabla de rutas. En especial, la puerta de enlace por defecto.

• Si no existe una ruta por defecto, el equipo no sabe por dónde salir.
• Si la puerta de enlace es incorrecta, la conectividad hacia fuera puede fallar aunque la red local funcione.

Este punto es especialmente útil para distinguir entre un fallo de interfaz y un fallo de enrutamiento.

4. traceroute o tracepath

Cuando el tráfico sale de la red local pero falla más adelante, me interesa saber en qué salto se interrumpe el camino. Para eso uso traceroute o tracepath.

Si la comunicación se rompe muy pronto, puede indicar un problema en la red del proveedor o en un punto intermedio del trayecto. No siempre da una respuesta definitiva, pero ayuda bastante a localizar el tramo del recorrido donde deja de avanzar el tráfico.

5. dig o nslookup

Cuando todo apunta a DNS, intento comprobarlo de forma explícita. Una prueba típica es consultar un dominio usando un resolver concreto, por ejemplo:

dig google.com @8.8.8.8

Si la resolución funciona correctamente con un DNS externo, el problema suele estar en el resolver configurado en la máquina, en el router o en la red local. Esto permite separar muy bien un fallo general de conectividad de un fallo concreto de resolución de nombres.

Lo importante no es el comando, sino el enfoque

Con el tiempo he visto que lo útil no es memorizar una lista de comandos sin contexto, sino entender qué está comprobando cada uno:

• Ping me dice si hay respuesta básica.
• ip a me confirma si la interfaz está bien configurada.
• ip route me dice si el sistema sabe por dónde salir.
• traceroute me ayuda a localizar el salto donde se rompe el camino.
• dig me permite aislar si el problema está en DNS.

Ese orden me resulta útil porque evita ir a ciegas. En lugar de probar cosas al azar, cada paso reduce el espacio de posibilidades.

Conclusión

Diagnosticar red en Linux no consiste en lanzar un ping y esperar que responda. El valor real está en encadenar comprobaciones simples pero bien pensadas para saber si el problema está en el equipo, en la red local, en la ruta de salida o en la resolución DNS.

Ese enfoque me ha resultado mucho más útil que cualquier respuesta rápida. No solo ayuda a resolver incidencias: también obliga a entender mejor qué está haciendo realmente el sistema cuando intenta comunicarse con el exterior.

← Volver a artículos