Guía ICMP: ping, traceroute y diagnóstico de red

ICMP viaja junto con IP para informar las condiciones de la red. Un host, enrutador o firewall puede enviar mensajes ICMP cuando no se puede alcanzar un destino, un paquete caduca en tránsito, se necesita fragmentación o una solicitud de eco de diagnóstico necesita una respuesta.

El flujo de trabajo ICMP más familiar es el ping. Un cliente envía una solicitud de eco y el objetivo responde con una respuesta de eco. El tiempo de ida y vuelta proporciona una señal rápida sobre la accesibilidad y la latencia, pero no prueba que un puerto de aplicación como el 443 o el 22 esté abierto.

ICMP no utiliza números de puerto TCP o UDP. Utiliza tipos de mensajes y códigos. Es por eso que una guía ICMP no debe tratarse como un artículo normal sobre puertos abiertos: usted decide si permite mensajes ICMP específicos, no si un demonio está escuchando en un puerto numerado.

Un verificador de puertos prueba la accesibilidad del servicio TCP o UDP. Ping prueba la accesibilidad de ICMP. Ambos son útiles, pero responden a preguntas diferentes. Un servidor puede bloquear el ping mientras HTTPS funciona o responder al ping mientras todos los puertos de la aplicación están cerrados.

El ping comprueba si un objetivo responde al eco ICMP y cuánto tiempo tarda el viaje de ida y vuelta. Es útil para verificaciones rápidas de accesibilidad, sondas de monitoreo y líneas de base de latencia.

Traceroute mapea la ruta enviando paquetes con valores TTL crecientes y leyendo mensajes ICMP excedidos en el tiempo de los enrutadores a lo largo del camino. Algunas plataformas utilizan sondas UDP o TCP para traceroute, pero los mensajes ICMP siguen siendo fundamentales para determinar cuántos diagnósticos de ruta informan sobre saltos intermedios.

Permita ICMP cuando los sistemas de monitoreo, los balanceadores de carga, los equipos de red o el personal de operaciones necesiten señales de accesibilidad y latencia. Para las redes internas, permitir ICMP controlado a menudo mejora la resolución de problemas y reduce los puntos ciegos.

Para los sistemas públicos, muchos equipos permiten respuestas de eco limitadas de fuentes de monitoreo confiables y permiten mensajes de error esenciales, como fragmentación necesaria o comportamiento de destino inalcanzable. La política exacta debe coincidir con el borde de su red, la postura DDoS y las necesidades de observabilidad.

Antes de bloquear o permitir ICMP, decida qué mensajes está controlando. La solicitud de eco, la respuesta de eco, el tiempo excedido, el destino inalcanzable y el comportamiento de paquetes demasiado grandes tienen diferentes impactos operativos.

Evite un bloqueo general a menos que comprenda la compensación. Bloquear todo ICMP puede interrumpir el descubrimiento de MTU, ocultar errores de enrutamiento útiles, hacer que el monitoreo sea menos preciso y obligar a los equipos a depurar con señales más débiles.

En Windows, el Firewall de Windows Defender tiene reglas de eco ICMP predefinidas que se pueden habilitar para perfiles y direcciones de origen seleccionados. Cuando sea posible, aplique reglas a redes confiables en lugar de permitir respuestas de ping públicas amplias de forma predeterminada.

En Linux, nftables, iptables, firewalld y los grupos de seguridad en la nube pueden permitir o limitar ICMP por tipo. Muchas distribuciones también exponen la configuración sysctl del kernel para el comportamiento de eco, pero la política de firewall suele ser el punto de control más claro.

En las plataformas en la nube, los grupos de seguridad a menudo tratan ICMP por separado de TCP y UDP. Verifique las políticas entrantes y salientes y recuerde que los balanceadores de carga, los bordes CDN y los controles DDoS del proveedor pueden manejar ICMP de manera diferente a los firewalls de instancia.

Utilice ping para probar la solicitud de eco y la respuesta. Utilice traceroute o tracert para inspeccionar la ruta e identificar dónde se detienen los paquetes, teniendo en cuenta que algunos enrutadores suprimen intencionalmente las respuestas ICMP o las limitan.

Si el ping falla pero una aplicación funciona, ICMP puede bloquearse mientras TCP o UDP estén permitidos. Si el ping funciona pero la aplicación falla, se puede acceder al objetivo en la capa de red, pero es posible que el puerto de servicio, la regla de firewall, el escucha o la aplicación específicos estén rotos.

Si el ping se agota, es posible que el objetivo esté inactivo, que falte una ruta, que el eco ICMP esté bloqueado o que un firewall intermedio esté descartando el mensaje. Los tiempos de espera no prueban automáticamente que el host esté desconectado.

Si traceroute se detiene en un salto, ese salto puede estar filtrando respuestas TTL caducadas o diagnósticos de limitación de velocidad. Si las transferencias grandes fallan mientras funcionan las solicitudes pequeñas, verifique el descubrimiento de MTU de ruta y si los mensajes con paquetes demasiado grandes están bloqueados.

Permitir ICMP deliberadamente en lugar de bloquear todo reflexivamente. Limite el tráfico de eco, alcance las respuestas públicas cuando corresponda y conserve los mensajes de error importantes necesarios para una red estable.

Supervise el volumen ICMP inusual, las fuentes falsificadas y los patrones de inundación en el borde. Para redes sensibles, combine la política ICMP con segmentación y monitoreo confiable en lugar de depender de la visibilidad del ping como límite de seguridad.