¿Por qué puedo rastrear a esta dirección IP, pero no hacer ping?

Tengo una dirección IP y puedo localizarla, pero no puedo hacer ping.

Ya ves, puedo traceroute 43.224.226.50:

dele-MBP:~ ll$ traceroute 43.224.226.50
traceroute to 43.224.226.50 (43.224.226.50), 64 hops max, 52 byte packets
 1  router.asus.com (192.168.2.1)  2.082 ms  1.039 ms  0.924 ms
 2  100.64.0.1 (100.64.0.1)  3.648 ms  3.795 ms  3.955 ms
 3  118.112.212.225 (118.112.212.225)  4.252 ms  4.569 ms  4.168 ms
 4  171.208.203.73 (171.208.203.73)  6.378 ms
    171.208.198.25 (171.208.198.25)  6.943 ms
    171.208.203.61 (171.208.203.61)  7.055 ms
 5  202.97.36.225 (202.97.36.225)  38.149 ms
    202.97.36.221 (202.97.36.221)  39.949 ms
    202.97.36.225 (202.97.36.225)  40.780 ms
 6  202.97.90.158 (202.97.90.158)  37.894 ms
    202.97.94.146 (202.97.94.146)  39.885 ms  39.354 ms
 7  202.97.38.166 (202.97.38.166)  45.324 ms
    202.97.39.149 (202.97.39.149)  40.097 ms
    202.97.94.77 (202.97.94.77)  40.580 ms
 8  202.97.51.118 (202.97.51.118)  374.218 ms
    202.97.27.238 (202.97.27.238)  187.573 ms
    202.97.86.138 (202.97.86.138)  197.524 ms
 9  218.30.53.190 (218.30.53.190)  201.597 ms
    218.30.54.190 (218.30.54.190)  194.194 ms
    218.30.53.190 (218.30.53.190)  204.027 ms
10  182.54.129.91 (182.54.129.91)  220.026 ms  282.360 ms
    et-11-1-5.r01.laxus01.us.bb.bgp.net (182.54.129.38)  185.700 ms
11  182.54.129.91 (182.54.129.91)  229.700 ms  508.509 ms  266.683 ms
12  * 212.95.128.2 (212.95.128.2)  565.161 ms *
13  43.224.226.50 (43.224.226.50)  200.531 ms  201.911 ms  191.566 ms

Pero no puedo hacer ping:

dele-MBP:~ ll$ ping 43.224.226.50
PING 43.224.226.50 (43.224.226.50): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11

Si hay una prohibición de ICMP, traceroutetampoco debería funcionar. ¿Cuál es el motivo?

Verifiqué que el firewall del servidor esté detenido.

En una pregunta similar aquí, Luke Savage lo explicó perfectamente:

Traceroute no es un protocolo en sí mismo, es una aplicación y los protocolos utilizados dependen de la implementación que esté utilizando. Principalmente esto es ICMP.

Hay dos implementaciones principales:

tracert: tracert es una aplicación de Windows que utiliza paquetes ICMP con un campo TTL incremental para asignar los saltos a la dirección de destino final.

traceroute: traceroute es una aplicación * nix disponible en la mayoría de los sistemas basados ​​en Linux, incluidos los dispositivos de red y los dispositivos Cisco. Esto utiliza paquetes UDP con un campo TTL incremental para mapear los saltos al destino final.

Es útil saber la diferencia entre estos, ya que algunas redes ahora bloquean ICMP de manera predeterminada, por lo que tanto PING como tracert de una máquina Windows fallarán, pero una ruta de seguimiento de un dispositivo Linux aún puede funcionar.

Para agregar a la respuesta de @ naïveRSA , si hay filtrado / cortafuegos en la ruta, uno también podría tener la situación en la que un paquete ICMP de "respuesta de eco" (ping) está bloqueado, pero se permite un paquete ICMP de "tiempo excedido" (tracert) . Esto daría los mismos resultados incluso cuando solo se utiliza ICMP (Windows).

En ambos casos (remitente que utiliza UDP o ICMP) la comunicación de error será ICMP (es decir, el nodo que responde a un paquete ping o trazador *).

Veamos qué pasa, ¿de acuerdo?

8.8.8.8 es un buen ejemplo, porque al menos desde mi ubicación, puedo alcanzarlo con traceroutey ping.

Primero intentemos ping 8.8.8.8y veamos qué sucede:

$ tcpdump -n host 8.8.8.8 or icmp
15:36:51.045994 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 0, length 64
15:36:51.062458 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 0, length 64
15:36:52.048350 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 1, length 64
15:36:52.073657 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 1, length 64

Por lo tanto, pingenvía una solicitud de eco ICMP y espera una respuesta de eco ICMP.

Ahora traceroute -n 8.8.8.8:

15:41:31.803324 IP 10.4.27.179.44838 > 8.8.8.8.33435: UDP, length 24
15:41:31.815184 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.815343 IP 10.4.27.179.44838 > 8.8.8.8.33436: UDP, length 24
15:41:31.819654 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.819791 IP 10.4.27.179.44838 > 8.8.8.8.33437: UDP, length 24
15:41:31.824609 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.824754 IP 10.4.27.179.44838 > 8.8.8.8.33438: UDP, length 24
15:41:31.830506 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.830649 IP 10.4.27.179.44838 > 8.8.8.8.33439: UDP, length 24
15:41:31.834469 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.834565 IP 10.4.27.179.44838 > 8.8.8.8.33440: UDP, length 24
15:41:31.840962 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.841061 IP 10.4.27.179.44838 > 8.8.8.8.33441: UDP, length 24
15:41:31.847440 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.847634 IP 10.4.27.179.44838 > 8.8.8.8.33442: UDP, length 24
15:41:31.853664 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.853761 IP 10.4.27.179.44838 > 8.8.8.8.33443: UDP, length 24
15:41:31.859221 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.859269 IP 10.4.27.179.44838 > 8.8.8.8.33444: UDP, length 24
15:41:31.864149 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.864192 IP 10.4.27.179.44838 > 8.8.8.8.33445: UDP, length 24
15:41:31.870843 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.870922 IP 10.4.27.179.44838 > 8.8.8.8.33446: UDP, length 24
15:41:31.876200 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.876352 IP 10.4.27.179.44838 > 8.8.8.8.33447: UDP, length 24
15:41:31.882148 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.882249 IP 10.4.27.179.44838 > 8.8.8.8.33448: UDP, length 24
15:41:31.890076 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.890156 IP 10.4.27.179.44838 > 8.8.8.8.33449: UDP, length 24
15:41:31.896100 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.896163 IP 10.4.27.179.44838 > 8.8.8.8.33450: UDP, length 24
15:41:31.905037 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.905235 IP 10.4.27.179.44838 > 8.8.8.8.33451: UDP, length 24
15:41:31.913206 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.913283 IP 10.4.27.179.44838 > 8.8.8.8.33452: UDP, length 24
15:41:31.923428 IP 108.170.242.241 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.923520 IP 10.4.27.179.44838 > 8.8.8.8.33453: UDP, length 24
15:41:31.932266 IP 108.170.237.9 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.932441 IP 10.4.27.179.44838 > 8.8.8.8.33454: UDP, length 24
15:41:31.939961 IP 209.85.251.9 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.940043 IP 10.4.27.179.44838 > 8.8.8.8.33455: UDP, length 24
15:41:31.947460 IP 108.170.237.21 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.947508 IP 10.4.27.179.44838 > 8.8.8.8.33456: UDP, length 24
15:41:31.954824 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33456 unreachable, length 36
15:41:31.954888 IP 10.4.27.179.44838 > 8.8.8.8.33457: UDP, length 24
15:41:31.963601 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33457 unreachable, length 36
15:41:31.963671 IP 10.4.27.179.44838 > 8.8.8.8.33458: UDP, length 24
15:41:31.972407 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33458 unreachable, length 36

Entonces traceroute, al menos la implementación que he instalado, no envía ICMP. Más bien, envía paquetes UDP.

Lo que no es visible en esta traza (aunque lo sería, si le diera tcpdumpa -vpara aumentar la verbosidad) es que las primeras sondas tienen un ttl de 1, y luego incrementa el ttl para las sondas posteriores. Esto hace que los enrutadores entre yo y 8.8.8.8 respondan con un error ICMP ttl excedido, que es cómo traceroute descubre los enrutadores entre aquí y allá.

Finalmente, el ttl es lo suficientemente largo como para llegar hasta 8.8.8.8, y 8.8.8.8 responde con un error inalcanzable del puerto ICMP, porque no tiene proceso escuchando en el puerto UDP 44838. Así es como Traceroute sabe que ha llegado al destino final .

Si algo entre aquí y allá está bloqueando todo ICMP, entonces ni ping ni traceroute funcionarán.

Pero generalmente no es el caso de que todo ICMP esté bloqueado, aunque tampoco es raro. Bloquear todo ICMP es problemático: por ejemplo, rompe el descubrimiento de MTU de ruta , que se basa en un error requerido de fragmentación ICMP. Los paquetes ICMP tienen un tipo y un código, y los operadores de red responsables solo bloquearán selectivamente algunos tipos o códigos, aquellos que representan un potencial de abuso o revelan información particular.

Por ejemplo, algunos hosts no responderán a una solicitud de eco ICMP y, por lo tanto, el ping no funcionará. La idea es que al no responder a los pings, es más difícil para un atacante descubrir qué hosts existen en la red. En la práctica, esto es cuestionable, ya que hay otras formas de buscar un host. Por ejemplo, uno puede enviar un TCP SYN al puerto 80 para buscar servidores web.

Muchos hosts tampoco enviarán un error inalcanzable de puerto ICMP cuando obtengan un datagrama UDP o un SYN TCP a un puerto en el que no tienen proceso de escucha, y esto interrumpe el traceroute. Una vez más, la idea es hacer que sea más difícil para un atacante mapear la red, pero nuevamente esto es solo una frustración menor para un atacante.

Debido a que traceroute es un programa y no un protocolo particular, tiene otras formas de sondeo. Todos confían en incrementar el TTL para descubrir los enrutadores, pero se pueden enviar diferentes tipos de sondas que pueden tener más o menos posibilidades de obtener una respuesta desde el punto final. Por ejemplo, my man tcpdumpenumera una -Iopción para usar sondas de eco ICMP, lo mismo que ping. También tiene -Tque usar sondas TCP SYN en lugar de UDP. Si sabe que un host responderá, pingentonces -Itiene mucho sentido. Si sabe que el host está escuchando en un puerto TCP en particular, entonces -Ttiene sentido, quizás junto con la -popción de seleccionar el puerto.

Desafortunadamente, estas opciones pueden requerir funciones raíz o especiales, por lo que UDP hace un valor predeterminado justo. De hecho, una herramienta similar tracepathtiene esto que decir en su página de manual:

DESCRIPCIÓN

Traza la ruta al destino descubriendo MTU a lo largo de esta ruta. Utiliza el puerto del puerto UDP o algún puerto aleatorio. Es similar a traceroute, solo que no requiere privilegios de superusuario y no tiene opciones sofisticadas.

TLDR; Los pings se pueden bloquear (bloqueo ICMP) en un host remoto, pero Traceroute aún puede encontrar la ruta hacia él utilizando el enrutamiento de red estándar UDP o TCP / IP (cualquier protocolo realmente; ref /networkengineering//a/36509/ 58968 ). Tenga en cuenta que su ping también puede llegar al host (a menos que tenga un cortafuegos muy inteligente que bloquee el tráfico de ping ICMP en alguna parte), el host simplemente no responde.

Linux usando UDP en lugar de ICMP para traceroute, el firewall no bloqueó ese puerto UDP

Puede instalar nmap (insecure.org) y usar nping con UDP o TCP y cualquier puerto. Funciona muy bien en redes con ping bloqueado saliente.

Para hacer ping a un servidor web nping --tcp -p 80,443

Para hacer ping a un servidor de hora nping --udp -p 123

https://nmap.org/book/nping-man.html

Una breve respuesta a su pregunta es que la pingutilidad se basa en el protocolo ICMP que a veces está bloqueado en el firewall de la red o en el firewall del dispositivo. La razón más común por la cual los administradores de red bloquean ICMP es para evitar el "escaneo" de la red que consideran un problema de seguridad. La tracerouteutilidad en Linux usa UDP, un protocolo completamente diferente, que en este caso no está bloqueado por los administradores de la red. UDP tiene una variedad de usos y bloquear esto provocaría que muchas cosas no se puedan usar en una red. El tipo de 'mensaje de control' ICMP que necesita pinges un subconjunto de un protocolo, lo que significa que el bloqueo de ese tipo de paquete ICMP causa menos problemas en una red y, por lo tanto, es más probable que sea bloqueado que UDP.