traceroute異なる宛先アドレスに対して(実際にはWindows のコマンド)を使用するとtracert、常に同じホップ カウントが取得されます。
たとえば、 の場合superuser.com、次のようになります。
Tracing route to superuser.com [151.101.1.69]
over a maximum of 30 hops:
1 6 ms 1 ms 1 ms 192.168.0.1
2 2 ms 3 ms 3 ms 10.201.0.1
3 4 ms 2 ms 2 ms angeldropsltd.com [103.242.217.37]
4 8 ms 4 ms 4 ms 151.101.1.69
Trace complete.
についてはmicrosoft.com、次のようになります。
Tracing route to microsoft.com [23.100.122.175]
over a maximum of 30 hops:
1 3 ms 3 ms 1 ms 192.168.0.1
2 5 ms 2 ms 2 ms 10.201.0.1
3 4 ms 2 ms 2 ms angeldropsltd.com [103.242.217.37]
4 7 ms 4 ms 4 ms 23.100.122.175
Trace complete.
これまで試した他のすべてのサイトでも同様です。
なぜこのようなことが起きるのか、考えられる理由を知りたいです。traceroute仕組みについては簡単に知っています。宛先が異なればホップ数も異なります。私のISP（エンジェルドロップス）にはすべての宛先サーバーが存在しない可能性があります直接接続されました。ISP が何かしているのではないかと思います。では、これが起こる理由は何でしょうか?
答え1
これをできるだけ詳しく説明します。しかし、ISP がなぜこれを行っているのかはわかりません。
まず、Traceroute の仕組みを理解することが重要です。Traceroute は、送信する IP パケットの TTL (Time To Live) 値を設定することで機能します。パケットが途中でホップするたびに、TTL が 1 ずつ減ります。TTL が 0 になったときに、パケットが目的の宛先に到達していない場合は、最後に到達したルーターの IP アドレスを含む ICMP 到達不能メッセージが送り返されます。
したがって、コマンドを発行するとtracert、Windows は TTL 値を増加させながら一連の ICMP パケットを送信します。最初のパケットは TTL 1 で送信され、次のパケットは TTL 2 で送信され、というように続きます。このようにして、宛先までのパス上にある各ルーターが ICMP 到達不能で応答した場合に、そのルーターを検出できます。パケットがドロップされた場合は、tracert から * * * 応答が返され、情報は返されません。
つまり、ここで起きているのは、ISP (AngelDrops) が TTL 設定を尊重していないということのようです。その代わりに、パケットが到達したときに、その情報を ISP が削除またはフィルタリングしているようです。そのため、パケットが AngelDrops に到達すると、AngelDrops はそれをはるかに高い「デフォルト」TTL で宛先に転送します。これにより、パケットは宛先までずっと移動し、表示される最終的な応答は宛先からの応答になります。
IP パケットの TTL は、パケットがネットワーク内で永久に循環し続けるネットワーク ループを防ぐために設計されています。
それが意味を成すといいのですが。では、なぜ ISP はそのようなことをするのでしょうか。よく分かりませんが、TTL の改ざんはネットワークのセキュリティ リスクになる可能性があると ISP が考え、フィルタリングしているのかもしれません。TTL データを尊重することは、ネットワークの適切な運用に必ずしも必要ではありません。
私は何も知らないのでエンジェルドロップス、この ISP に何か非標準のものがある可能性があります。ワイヤレス、VPN サービスなどです。奇妙なことが起こる技術的な理由はいくつか考えられます。
トレースルートから判断すると、何らかの共有インターネット サービスを使用しているようです。実際のパブリック IP を取得していないため、複数のユーザーで同じパブリック IP を共有している NAT 化されたネットワークを使用している可能性があります。これですべてが説明できます。