pingではなくこのIPアドレスにtracerouteできるのはなぜですか？

IPアドレスがあり、tracerouteできますが、pingできません。

わかります、私は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

しかし、私はそれを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

ICMPが禁止されている場合は、機能しtracerouteません。その理由は何ですか？

サーバーのファイアウォールが停止していることを確認しました。

ここでの同様の質問で、 Luke Savageはそれを完璧に説明しました。

Tracerouteはプロトコルそのものではなく、アプリケーションであり、使用するプロトコルは使用している実装によって異なります。主にこれはICMPです。

主に2つの実装があります。

tracert-tracertは、増分TTLフィールドとしてICMPパケットを使用して、ホップを最終宛先アドレスにマッピングするWindowsアプリケーションです。

traceroute-tracerouteは、ネットワークデバイスを含むほとんどのLinuxベースのシステムおよびCiscoデバイスで利用可能な* nixアプリケーションです。これは、増分TTLフィールドを持つUDPパケットを使用して、ホップを最終宛先にマップします。

これらの違いは、一部のネットワークがデフォルトでICMPをブロックするようになったため、WindowsマシンからのPINGとtracertの両方が失敗しますが、Linuxデバイスからのtracerouteは引き続き機能するため、便利です。

@naïveRSAの回答に追加するために、パスにフィルタリング/ファイアウォールがある場合、ICMP「エコー応答」（ping）パケットはブロックされるが、ICMP「時間超過」（tracert）パケットが許可される状況もあります。ICMP（Windows）のみが使用されている場合でも、これにより同じ結果が得られます。

両方の場合（UDPまたはICMPを使用する送信者）、エラー通信はICMP（つまり、pingまたはtracer *パケットに応答するノード）になります。

何が起こるか見てみましょうか？

8.8.8.8は良い例です。少なくとも私の場所から、との両方でアクセスできるtracerouteからpingです。

最初にping 8.8.8.8何が起こるか見てみましょう：

$ 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

したがってping、ICMPエコー要求を送信し、ICMPエコー応答を予期します。

今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

だからtraceroute、少なくとも私がインストールした実装はICMPを送信しません。むしろ、UDPパケットを送信します。

このトレースに表示されないのは（詳細度を上げるためにtcpdumpa -vを指定した場合）、最初のプローブのttlが1であり、その後のプローブのttlが増加することです。これにより、私と8.8.8.8の間のルーターはICMP ttl超過エラーで応答します。これは、tracerouteがこことそこの間のルーターを検出する方法です。

最終的に、ttlは8.8.8.8に達するのに十分な長さであり、UDPポート44838でリッスンするプロセスがないため、8.8.8.8はICMPポート到達不能エラーで応答します。これは、tracerouteが最終宛先に到達したことを知る方法です。

こことそこの間の何かがすべての ICMPをブロックしている場合、pingもtracerouteも機能しません。

しかし、すべての ICMPがブロックされることは通常ありませんが、まれでもありません。すべてのICMPをブロックすることには問題があります。たとえば、ICMPフラグメンテーションが必要なエラーに依存するパスMTUディスカバリーを中断します。ICMPパケットにはタイプとコードがあり、責任のあるネットワークオペレーターは、悪用される可能性のあるタイプまたはコード、特定の情報を開示するタイプまたはコードのみを選択的にブロックします。

たとえば、一部のホストはICMPエコー要求にまったく応答しないため、pingは機能しません。アイデアは、pingに応答しないことにより、ネットワーク上に存在するホストを攻撃者が発見するのが難しくなるというものです。ホストをプローブする他の方法があるため、実際にはこれは疑わしいです。たとえば、TCP SYNをポート80に送信してWebサーバーを見つけることができます。

また、多くのホストは、プロセスがリッスンしていないポートにUDPデータグラムまたはTCP SYNを取得した場合、ICMPポート到達不能エラーを送信しません。これにより、tracerouteが破損します。繰り返しになりますが、攻撃者がネットワークをマップするのをより困難にするという考え方ですが、これも攻撃者にとってはささいなフラストレーションにすぎません。

tracerouteは特定のプロトコルではなくプログラムであるため、他の調査方法があります。それらはすべてTTLの増分に依存してルーターを検出しますが、エンドポイントからの応答を引き出す可能性が多少異なる可能性のあるさまざまな種類のプローブを送信できます。たとえば、myにman tcpdumpは、-Ipingと同じICMPエコープローブを使用するオプションがリストされています。また-T、UDPの代わりにTCP SYNプローブを使用する必要があります。あなたが知っている場合は、ホストに応答しますping、その後-I多くの意味になります。ホストが特定のTCPポートでリッスンしていることがわかっている場合は-T、おそらく-p、ポートを選択するオプションと組み合わせて意味があります。

残念ながら、これらのオプションにはルートまたは特別な機能が必要な場合があるため、UDPはかなりデフォルトになっています。実際、同様のツールのtracepathmanページには次のように書かれています：

記述

このパスに沿ってMTUを検出する宛先へのパスをトレースします。UDPポートポートまたはランダムポートを使用します。tracerouteに似ており、スーパーユーザー特権のみを必要とせず、特別なオプションはありません。

TLDR; pingはリモートホスト上でブロック（ICMPブロック）できますが、tracerouteは標準のネットワークルーティングUDPまたはTCP / IP（実際には任意のプロトコル; ref /networkengineering//a/36509/ 58968）。pingがホストに到達する可能性が高いことに注意してください（ICMP pingトラフィックをどこかでブロックする非常にスマートなファイアウォールがない場合を除く）、ホストは応答しません。

Linuxはtraceroute にICMPの代わりにUDPを使用し、ファイアウォールはそのUDPポートをブロックしませんでした

nmap（insecure.org）をインストールし、UDPまたはTCPと任意のポートでnpingを使用できます。pingがアウトバウンドをブロックしているネットワークでうまく機能します。

Webサーバーにpingを実行するにはnping --tcp -p 80,443

タイムサーバーにpingするにはnping --udp -p 123

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

あなたの質問に対する簡単な答えは、pingユーティリティがICMPプロトコルに依存していることです。ICMPプロトコルは、ネットワークファイアウォールまたはデバイス自体のファイアウォールでブロックされることがあります。ネットワーク管理者がICMPをブロックする最も一般的な理由は、セキュリティ上の懸念があると考えられるネットワークの「スキャン」を防ぐためです。tracerouteLinux のユーティリティは、完全に異なるプロトコルであるUDPを使用します。この場合、ネットワーク管理者によってブロックされません。UDPにはさまざまな用途があり、これをブロックすると多くのことがネットワーク上で使用できなくなります。必要なICMP '制御メッセージ'のタイプはpingプロトコルのサブセットです。つまり、そのタイプのICMPパケットをブロックすると、ネットワークでの問題が少なくなり、UDPよりもブロックされる可能性が高くなります。