“ping: command not found” — Cómo instalar y usar Ping en Ubuntu

El error `ping: command not found` aparece en Ubuntu cuando el paquete iputils-ping está ausente del sistema. Esto es común en instalaciones mínimas, imágenes de VPS en la nube y contenedores Docker donde las utilidades no esenciales se eliminan para reducir el tamaño de la imagen. La solución es un único comando `apt`: `sudo apt install iputils-ping`. Este artículo explica por qué falta el paquete, cómo instalarlo correctamente en diferentes entornos Ubuntu y cómo usar `ping` de manera efectiva para diagnósticos de red en el mundo real.

Qué hace realmente el comando Ping

`ping` es una utilidad de diagnóstico de red que envía paquetes de Solicitud de Eco ICMP a un host de destino y escucha las respuestas de Eco ICMP. El tiempo de ida y vuelta (RTT) de cada paquete se mide en milisegundos, lo que proporciona una señal precisa sobre la latencia de red, la accesibilidad y la estabilidad.

Internamente, `ping` se basa en el Protocolo de Mensajes de Control de Internet (ICMP), definido en RFC 792. Opera en la capa de red (Capa 3 del modelo OSI), lo que significa que omite TCP y UDP por completo. Esto lo hace útil para aislar si un problema de conectividad está en el nivel de enrutamiento IP frente a la capa de aplicación o transporte.

Casos de uso principales

• Prueba de accesibilidad — Confirma si un host remoto está activo y respondiendo.
• Medición de latencia — Reporta el RTT en milisegundos; un RTT elevado indica congestión de red o un servidor geográficamente distante.
• Detección de pérdida de paquetes — Las respuestas ICMP descartadas apuntan a fallos de hardware, enrutadores sobrecargados o enlaces inestables.
• Validación de rutas de red — Útil para verificar que una ruta recién configurada o una regla de firewall no bloquee el tráfico.
• Detección de firewall y filtrado ICMP — Si `ping` agota el tiempo de espera pero los servicios TCP responden, el firewall probablemente está descartando el tráfico ICMP específicamente.
• Verificación de resolución DNS — Hacer ping a un nombre de host (en lugar de una IP) confirma que la resolución DNS está funcionando correctamente.

¿Por qué falta Ping en Ubuntu?

La instalación completa de escritorio de Ubuntu incluye `ping` de forma predeterminada. Sin embargo, varios escenarios comunes resultan en un sistema donde el binario está ausente:

• Instalaciones mínimas de servidor — La ISO mínima de Ubuntu Server omite deliberadamente muchas utilidades para mantener un tamaño reducido.
• Imágenes de nube y VPS — Los proveedores a menudo distribuyen imágenes de Ubuntu reducidas para un aprovisionamiento más rápido. Si está ejecutando una instancia de Hosting VPS, puede encontrar esto en el primer arranque.
• Contenedores Docker y LXC — Las imágenes base oficiales de Ubuntu (`ubuntu:22.04`, `ubuntu:24.04`) no incluyen `iputils-ping` de forma predeterminada.
• Despliegues automatizados y pipelines CI/CD — Los entornos con scripts construidos a partir de imágenes base mínimas frecuentemente carecen de herramientas de red estándar.
• Entornos Chroot y WSL — El Subsistema de Windows para Linux y las jaulas chroot también pueden omitir el paquete.

El binario en sí reside en `/bin/ping` (o `/usr/bin/ping` en sistemas más nuevos). Si esa ruta no existe, el shell devuelve `command not found`. Puede confirmar si el binario simplemente falta o está en una ruta no estándar con:

“`bash

which ping

or

type ping

“`

Si ambos no devuelven nada, el paquete no está instalado.

Cómo instalar Ping en Ubuntu (paso a paso)

Paso 1: Actualizar el índice de paquetes

Siempre actualice el índice de paquetes local antes de instalar cualquier cosa. Esto garantiza que `apt` resuelva las últimas versiones de paquetes disponibles y evite errores de metadatos obsoletos:

“`bash

sudo apt update

“`

En un Servidor Dedicado o un VPS recién aprovisionado, este paso es especialmente importante porque la caché de paquetes puede estar desactualizada días o semanas.

Paso 2: Instalar iputils-ping

El binario `ping` en Ubuntu es proporcionado por el paquete iputils-ping, que forma parte del conjunto más amplio `iputils` mantenido por la comunidad del kernel de Linux:

“`bash

sudo apt install iputils-ping

“`

Cuando se le solicite con `Do you want to continue? [Y/n]`, presione `Y` y `Enter`. El paquete es pequeño (normalmente menos de 100 KB) y se instala en segundos.

Paso 3: Verificar la instalación

Confirme que el binario está disponible y es funcional:

“`bash

ping -c 4 google.com

“`

El indicador `-c 4` limita la salida a 4 paquetes. Una respuesta exitosa se ve así:

“`

PING google.com (142.250.185.46) 56(84) bytes of data.

64 bytes from lga34s32-in-f14.1e100.net (142.250.185.46): icmp_seq=1 ttl=118 time=12.4 ms

64 bytes from lga34s32-in-f14.1e100.net (142.250.185.46): icmp_seq=2 ttl=118 time=11.9 ms

64 bytes from lga34s32-in-f14.1e100.net (142.250.185.46): icmp_seq=3 ttl=118 time=12.1 ms

64 bytes from lga34s32-in-f14.1e100.net (142.250.185.46): icmp_seq=4 ttl=118 time=12.3 ms

— google.com ping statistics —

4 packets transmitted, 4 received, 0% packet loss, time 3004ms

rtt min/avg/max/mdev = 11.9/12.175/12.4/0.185 ms

“`

Desea ver 0% de pérdida de paquetes y valores RTT consistentes. Una alta varianza en el RTT (`mdev`) indica jitter de red, lo que importa para aplicaciones sensibles a la latencia.

Paso 4: Verificar la ruta del binario instalado y los permisos

“`bash

which ping

ls -la $(which ping)

“`

En Ubuntu 20.04 y versiones posteriores, `ping` ya no requiere el bit setuid. En su lugar, utiliza capacidades de Linux (`cap_net_raw`) para enviar paquetes ICMP sin procesar sin privilegios de root. Puede inspeccionarlo con:

“`bash

getcap $(which ping)

Expected output: /usr/bin/ping cap_net_raw=ep

“`

Esta es una mejora de seguridad respecto a las implementaciones antiguas basadas en setuid.

Instalación de Ping dentro de un contenedor Docker

Si está trabajando dentro de un contenedor Docker basado en Ubuntu, el proceso es idéntico, pero es posible que deba ejecutar comandos como root (el usuario predeterminado en la mayoría de las imágenes base):

“`bash

apt update && apt install -y iputils-ping

“`

El indicador `-y` confirma automáticamente el mensaje, lo cual es esencial para compilaciones de Dockerfile no interactivas. Para incorporar `ping` en una imagen personalizada, agréguelo a su `Dockerfile`:

“`dockerfile

FROM ubuntu:22.04

RUN apt update && apt install -y iputils-ping && rm -rf /var/lib/apt/lists/*

“`

La línea `rm -rf /var/lib/apt/lists/*` borra la caché de paquetes para mantener pequeña la capa de imagen — una práctica recomendada para imágenes de contenedores de producción.

Instalación de Ping en Ubuntu sin acceso a Internet (método sin conexión)

En servidores con espacio de aire o segmentos de red aislados, `apt` no puede llegar a repositorios externos. En este caso, tiene dos opciones:

Opción 1: Transferir el paquete .deb manualmente

En una máquina con acceso a Internet, descargue el paquete:

“`bash

apt download iputils-ping

“`

Transfiera el archivo `.deb` a la máquina de destino mediante `scp` o una unidad USB, luego instálelo:

“`bash

sudo dpkg -i iputils-ping_*.deb

“`

Opción 2: Usar un espejo local o un repositorio APT interno

Configure `/etc/apt/sources.list` para que apunte a un espejo interno que tenga el paquete en caché. Este es el enfoque estándar para entornos empresariales con controles estrictos de salida.

Herramientas alternativas si Ping está bloqueado o no disponible

El tráfico ICMP es frecuentemente bloqueado por firewalls, grupos de seguridad en la nube o proveedores de hosting. Si `ping` agota el tiempo de espera constantemente a pesar de que el host es accesible, considere estas alternativas:

Información clave: `mtr` (Matt’s Traceroute) es posiblemente más útil que `ping` para diagnosticar pérdida de paquetes intermitente porque sondea continuamente cada salto en la ruta y muestra los porcentajes de pérdida por salto en tiempo real. En servidores de producción — incluidos los que ejecutan VPS con cPanel — `mtr` debería ser su primera herramienta cuando un cliente reporta problemas de conectividad esporádicos.

Errores comunes y cómo solucionarlos

"permission denied" o "operation not permitted"

Esto ocurre cuando la capacidad `cap_net_raw` falta en el binario, o cuando se ejecuta dentro de un contenedor con capacidades de Linux restringidas:

“`bash

Check capabilities

getcap /usr/bin/ping

Restore if missing

sudo setcap cap_net_raw+ep /usr/bin/ping

“`

Dentro de Docker, es posible que deba ejecutar el contenedor con `–cap-add NET_RAW` o `–privileged` (use `–privileged` solo en entornos de confianza y aislados):

“`bash

docker run –cap-add NET_RAW ubuntu:22.04 ping -c 2 8.8.8.8

“`

"unable to locate package iputils-ping"

Esto significa que `apt` no puede encontrar el paquete en su lista de repositorios actual. Causas y soluciones:

1. Índice de paquetes obsoleto — Ejecute primero `sudo apt update`.
2. sources.list dañado — Verifique que `/etc/apt/sources.list` contenga entradas de repositorio de Ubuntu válidas.
3. Contenedor mínimo sin repositorio universe — Agregue el repositorio universe: `sudo add-apt-repository universe`.
4. Sin conectividad de red — Pruebe con `curl https://archive.ubuntu.com` para confirmar que la máquina puede llegar a los servidores de paquetes de Ubuntu.

"ping: connect: Network is unreachable"

El binario está instalado, pero el sistema no tiene una ruta de red configurada. Este es un problema de configuración de red, no un problema de `ping`. Diagnostique con:

“`bash

ip route show

ip addr show

“`

Si falta la ruta predeterminada, agréguela:

“`bash

sudo ip route add default via <gateway_ip>

“`

"Name or service not known" (fallo de DNS)

`ping google.com` resuelve el nombre de host antes de enviar paquetes ICMP. Si DNS está roto, verá este error. Pruebe haciendo ping a una IP directamente:

“`bash

ping -c 2 8.8.8.8

“`

Si eso tiene éxito, el problema es específico de DNS. Verifique `/etc/resolv.conf` y asegúrese de que haya un servidor de nombres válido configurado.

Indicadores esenciales de Ping que todo administrador de sistemas debe conocer

Consejo práctico: Use `ping -s 1472 -M do <gateway>` para probar el descubrimiento de MTU de ruta. El indicador `-M do` establece el bit “No Fragmentar”; si el paquete supera el MTU de la ruta, recibirá un mensaje ICMP “Frag needed”, que es la forma definitiva de diagnosticar agujeros negros TCP relacionados con MTU — un problema común en túneles VPN y ciertas configuraciones de red en la nube.

Consideraciones de seguridad: cuándo deshabilitar ICMP

Si bien `ping` es invaluable para diagnósticos, el ICMP sin restricciones en servidores de cara al público conlleva riesgos:

• Ataques de inundación ICMP (ping flood) — El tráfico ICMP de alto volumen puede saturar el ancho de banda o la CPU en hardware antiguo.
• Reconocimiento de red — Responder a ICMP revela que un host está activo, lo que ayuda a los atacantes a mapear su infraestructura.
• Ataques Smurf — Ataques de difusión ICMP amplificados (en gran medida mitigados en redes modernas, pero aún relevantes en infraestructura heredada).

Para servidores de producción — particularmente los que alojan aplicaciones web o servicios de Hosting de Correo Electrónico — una política razonable es permitir ICMP solo desde IPs de administración de confianza, y limitar la tasa o bloquear ICMP desde Internet público usando `iptables` o `nftables`:

“`bash

Allow ICMP from a trusted management IP

sudo iptables -A INPUT -p icmp –icmp-type echo-request -s 203.0.113.10 -j ACCEPT

Rate-limit ICMP from all other sources (max 10 pings/second)

sudo iptables -A INPUT -p icmp –icmp-type echo-request -m limit –limit 10/second -j ACCEPT

Drop remaining ICMP echo requests

sudo iptables -A INPUT -p icmp –icmp-type echo-request -j DROP

“`

Este enfoque preserva la utilidad de diagnóstico para su equipo mientras reduce la superficie de ataque.

Ping en el contexto de entornos de servidor y hosting

Comprender el comportamiento de `ping` varía significativamente según su entorno de hosting:

Hosting Compartido: En los planes de Hosting Web Compartido, normalmente no tiene acceso al shell. Los diagnósticos basados en ping deben realizarse desde una máquina local o un servicio de monitoreo externo que apunte a la IP de su servidor.

VPS y Servidores Dedicados: El acceso root completo significa que puede instalar `iputils-ping` y ejecutar todos los comandos de diagnóstico libremente. Aquí es donde `ping`, `mtr` y `traceroute` son más valiosos para solucionar problemas de conectividad entre su servidor y los proveedores upstream.

Servidores GPU: Los entornos de cómputo de alto rendimiento, como los nodos de Hosting GPU, a menudo ejecutan imágenes de SO mínimas para maximizar la asignación de recursos a las cargas de trabajo de cómputo. Ping y otras herramientas de diagnóstico suelen estar ausentes y deben instalarse explícitamente.

Contenedores y Orquestación: En pods de Kubernetes o servicios de Docker Swarm, las herramientas de depuración de red suelen estar ausentes de las imágenes de producción. El patrón recomendado es usar un contenedor sidecar de depuración dedicado o un pod de depuración efímero (`kubectl debug`) en lugar de saturar las imágenes de producción con utilidades de diagnóstico.

Matriz de decisión de referencia rápida

Use esta matriz para determinar la acción correcta según su escenario específico:

Lista de verificación técnica: hacer que Ping funcione correctamente

• [ ] Ejecute `sudo apt update` antes de intentar la instalación
• [ ] Instale con `sudo apt install iputils-ping`
• [ ] Confirme la ruta del binario: `which ping` debería devolver `/usr/bin/ping`
• [ ] Verifique las capacidades: `getcap /usr/bin/ping` debería mostrar `cap_net_raw=ep`
• [ ] Pruebe primero con IP (`ping -c 2 8.8.8.8`) antes de probar con nombre de host
• [ ] Si el nombre de host falla pero la IP tiene éxito, diagnostique DNS mediante `/etc/resolv.conf`
• [ ] Para contenedores, agregue `–cap-add NET_RAW` si persisten los errores de permisos
• [ ] En servidores de producción, aplique limitación de tasa `iptables` para ICMP público
• [ ] Considere `mtr` para problemas de conectividad persistentes o intermitentes
• [ ] Para entornos sin conexión, use `apt download` en una máquina conectada y transfiera el `.deb`

—

Preguntas frecuentes

P: ¿Por qué Ubuntu no incluye ping de forma predeterminada?

Las imágenes mínimas y de servidor de Ubuntu omiten `iputils-ping` para reducir el tamaño de la instalación. El paquete no forma parte de las dependencias requeridas del sistema base, por lo que se excluye a menos que se solicite explícitamente. Instálelo con `sudo apt install iputils-ping`.

P: ¿Hay diferencia entre `ping` y `ping6` en Ubuntu?

En los sistemas Ubuntu modernos (18.04 y posteriores), el binario `ping` maneja tanto IPv4 como IPv6. Use `ping -4` para forzar IPv4 o `ping -6` para forzar IPv6. El binario independiente `ping6` está obsoleto y ya no se distribuye por separado en las versiones actuales de `iputils-ping`.

P: ¿Por qué ping funciona como root pero falla para usuarios regulares?

Esto indica que la capacidad `cap_net_raw` falta en el binario. Ejecute `sudo setcap cap_net_raw+ep /usr/bin/ping` para restaurarla. Alternativamente, reinstalar el paquete (`sudo apt install –reinstall iputils-ping`) restablecerá las capacidades del binario a sus valores predeterminados correctos.

P: ¿Puedo usar ping para probar si un puerto específico está abierto?

No. `ping` usa ICMP y no tiene concepto de puertos TCP/UDP. Para probar si un puerto específico está abierto, use `nc -zv <host> <port>` (netcat) o `nmap -p <port> <host>`. Un host puede ser accesible mediante `ping` mientras tiene un puerto específico bloqueado, o viceversa.

P: ¿Qué significa un valor alto de `mdev` (desviación estándar) en la salida de ping?

`mdev` mide la varianza en el RTT entre paquetes. Un valor alto de `mdev` (por ejemplo, 20–50 ms en una conexión con un RTT promedio de 30 ms) indica jitter de red — tiempos de entrega de paquetes inconsistentes. Esto es particularmente perjudicial para aplicaciones en tiempo real como VoIP, videoconferencias y juegos en línea. El jitter persistente generalmente apunta a congestión en un enrutador intermedio, una interfaz de red defectuosa o una política QoS mal configurada.