Por que posso rastrear esse endereço IP, mas não executar ping?

Eu tenho um endereço IP e posso rastrear, mas não consigo executar ping.

Você vê, eu posso rastrear 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

Mas não consigo executar 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

Se houver uma proibição do ICMP, traceroutetambém não deve funcionar. Qual o motivo disso?

Eu verifiquei se o firewall do servidor está parado.

Em uma pergunta semelhante aqui, Luke Savage explicou perfeitamente:

O Traceroute não é um protocolo em si, é um aplicativo e os protocolos usados ​​dependem da implementação que você está usando. Principalmente isso é ICMP.

Existem duas implementações principais:

tracert - tracert é um aplicativo do Windows que utiliza pacotes ICMP com o campo TTL incrementado para mapear os saltos para o endereço de destino final.

traceroute - traceroute é um aplicativo * nix disponível na maioria dos sistemas baseados em Linux, incluindo dispositivos de rede e dispositivos Cisco. Isso usa pacotes UDP com um campo TTL de incremento para mapear os saltos para o destino final.

A diferença entre eles é útil, já que algumas redes agora bloqueiam o ICMP por padrão, de modo que o PING e o tracert de uma máquina Windows falhem, mas um traceroute de um dispositivo Linux ainda pode funcionar.

Para adicionar à resposta da @ naïveRSA , se houver filtragem / firewall no caminho, também é possível que um pacote de "resposta de eco" (ping) do ICMP esteja bloqueado, mas um pacote de "tempo excedido" (tracert) do ICMP seja permitido . Isso daria os mesmos resultados mesmo quando apenas o ICMP (Windows) for usado.

Nos dois casos (remetente usando UDP ou ICMP), a comunicação de erro será ICMP (ou seja, o nó que responde a um pacote ping ou tracer *).

Vejamos o que acontece, não é?

8.8.8.8 é um bom exemplo, porque pelo menos da minha localização, posso acessá-lo com traceroutee ping.

Primeiro vamos tentar ping 8.8.8.8ver o que acontece:

$ 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

Portanto, pingenvia uma solicitação de eco do ICMP e espera uma resposta de eco do ICMP.

Agora 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

Portanto traceroute, pelo menos a implementação que instalei, não envia ICMP. Em vez disso, ele envia pacotes UDP.

O que não é visível nesta trace (apesar de que seria, se eu dei tcpdumpum -vpara aumentar a verbosidade) é que as primeiras sondas têm um TTL de 1, e em seguida, ele incrementa o TTL para sondas posteriores. Isso faz com que os roteadores entre mim e 8.8.8.8 respondam com um erro excedido de ICMP ttl, que é como o traceroute descobre os roteadores entre aqui e ali.

Eventualmente, o ttl é longo o suficiente para chegar até 8.8.8.8 e 8.8.8.8 responde com um erro inacessível da porta ICMP, porque não possui processo de escuta na porta UDP 44838. É assim que o traceroute sabe que chegou ao destino final .

Se algo entre aqui e ali estiver bloqueando todo o ICMP, nem o ping nem o traceroute funcionarão.

Mas geralmente não é o caso de todo o ICMP estar bloqueado, embora também não seja raro. Bloquear todo o ICMP é problemático: por exemplo, ele interrompe a descoberta da MTU do caminho , que depende de um erro necessário à fragmentação do ICMP. Os pacotes ICMP têm um tipo e um código, e os operadores de rede responsáveis ​​apenas bloquearão seletivamente alguns tipos ou códigos, aqueles que apresentam potencial para abuso ou revelam informações específicas.

Por exemplo, alguns hosts não respondem a uma solicitação de eco do ICMP e, portanto, o ping não funciona. A idéia é que, ao não responder aos pings, é mais difícil para um invasor descobrir quais hosts existem na rede. Na prática, isso é questionável, pois existem outras maneiras de investigar um host. Por exemplo, pode-se enviar um TCP SYN para a porta 80 para encontrar servidores da web.

Muitos hosts também não enviam um erro inacessível da porta ICMP quando obtêm um datagrama UDP ou um TCP SYN em uma porta na qual eles não têm processo de escuta, e isso interrompe o traceroute. Novamente, a idéia é tornar mais difícil para um invasor mapear a rede, mas, novamente, isso é apenas uma pequena frustração para um invasor.

Como o traceroute é um programa e não um protocolo específico, ele tem outras maneiras de investigar. Todos eles contam com o incremento do TTL para descobrir os roteadores, mas podem ser enviados diferentes tipos de análises que podem ter mais ou menos chance de obter uma resposta do ponto de extremidade. Por exemplo, minhas man tcpdumplistas incluem uma -Iopção para usar as sondas de eco ICMP, da mesma forma que o ping. Ele também deve -Tusar testes TCP SYN em vez de UDP. Se você sabe que um host responderá ping, -Ifaz muito sentido. Se você sabe que o host está escutando uma porta TCP específica, -Tfaz sentido, talvez em conjunto com a -popção de selecionar a porta.

Infelizmente, essas opções podem exigir recursos raiz ou especiais, portanto, o UDP faz um padrão justo. De fato, uma ferramenta semelhante,, tracepathtem isso a dizer em sua página de manual:

DESCRIÇÃO

Ele rastreia o caminho até o destino, descobrindo o MTU ao longo desse caminho. Ele usa a porta UDP ou alguma porta aleatória. É semelhante ao traceroute, apenas não requer privilégios de superusuário e não possui opções sofisticadas.

TLDR; os pings podem ser bloqueados (bloco ICMP) em um host remoto, mas o traceroute ainda pode encontrar a rota para ele usando o roteamento de rede padrão UDP ou TCP / IP (qualquer protocolo realmente; ref /networkengineering//a/36509/ 58968 ). Observe que seu ping provavelmente também pode alcançar o host (a menos que você tenha um firewall muito inteligente bloqueando o tráfego de ping ICMP em algum lugar), o host simplesmente não responde.

Linux usando UDP em vez de ICMP para traceroute, o firewall não bloqueou essa porta UDP

Você pode instalar o nmap (insecure.org) e usar o nping com UDP ou TCP e qualquer porta. Funciona muito bem em redes com saída bloqueada por ping.

Para executar ping em um servidor da web nping --tcp -p 80,443

Para executar ping em um servidor de horário nping --udp -p 123

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

Uma breve resposta à sua pergunta é que o pingutilitário depende do protocolo ICMP, que às vezes é bloqueado no firewall da rede ou no firewall do próprio dispositivo. O motivo mais comum pelo qual os administradores de rede bloqueiam o ICMP é impedir a "varredura" da rede, que eles consideram uma preocupação de segurança. O tracerouteutilitário no Linux usa UDP, um protocolo completamente diferente, que neste caso não é bloqueado pelos administradores da rede. O UDP tem vários usos e o bloqueio disso faria com que muitas coisas fossem inutilizáveis ​​em uma rede. O tipo de 'mensagem de controle' do ICMP necessária pingé um subconjunto de um protocolo, o que significa que o bloqueio desse tipo de pacote ICMP causa menos problemas em uma rede e, portanto, é mais provável que seja bloqueado que o UDP.