☰

宛先の後に追加のホップで traceroute が終了するのはなぜですか?

tag-icon • tag-icon traceroute
宛先の後に追加のホップで traceroute が終了するのはなぜですか?

トラフィックをブロックするものがない場合は、traceroute通常、最後のホップとして宛先 IP で終了します。(この場合は 10.1.1.10)

普通はtracerouteこんな感じです。

user@linux:~$ traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 60 byte packets
 1  10.2.8.2 (10.2.8.2)  0.572 ms  0.692 ms  0.837 ms
 2  10.1.9.50 (10.1.9.50)  202.638 ms 10.1.9.78 (10.1.9.78)  202.547 ms 10.1.9.50 (10.1.9.50)  202.139 ms
 3  10.1.4.9 (10.1.4.9)  202.508 ms  202.483 ms 10.1.4.13 (10.1.4.13)  204.149 ms
 4  10.1.1.10 (10.1.1.10)  202.133 ms  202.100 ms  202.692 ms
user@linux:~$

最近、出力に追加のホップ (10.1.1.9) があるという問題が発生しましたtraceroute(ホップ 5 を参照)。

送信元 IP アドレス: 10.2.8.8

user@linux:~$ ifconfig | head -2
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.2.8.8  netmask 255.255.255.0  broadcast 10.2.8.255
user@linux:~$

宛先 IP アドレス: 10.1.1.10

追加ホップ: 10.1.1.9 ???

user@linux:~$ traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 60 byte packets
 1  10.2.8.2 (10.2.8.2)  0.572 ms  0.692 ms  0.837 ms
 2  10.1.9.50 (10.1.9.50)  202.638 ms 10.1.9.78 (10.1.9.78)  202.547 ms 10.1.9.50 (10.1.9.50)  202.139 ms
 3  10.1.4.9 (10.1.4.9)  202.508 ms  202.483 ms 10.1.4.13 (10.1.4.13)  204.149 ms
 4  10.1.1.10 (10.1.1.10)  202.133 ms  202.100 ms  202.692 ms
 5  10.1.1.9 (10.1.1.9)  6201.720 ms !H * *
user@linux:~$

また、ホップ2と3を見ると、追加のIPアドレス（10.1.9.78と10.1.9.50）があります。

なぜこんなことが起きたのでしょうか? こんなことは今まで見たことがありません。

これはサーバーの設定が原因でしょうか?

答え1

tracerouteは、Time-to-Live (TTL) フィールドが順次増加する UDP または ICMP エコー パケットを送信することによって機能します。TTL は、パケットを処理する各ルータによって 1 ずつ減少します。

探査機に対しては2種類の反応が期待される。

  • ルータが TTL を減算したときに TTL が 0 に達すると、ルータは ICMP Time-Exceeded メッセージで応答し、パケットを転送しません。
  • 最終宛先は、ICMP ポート到達不能メッセージ (UDP の場合) または ICMP エコー応答メッセージ (ICMP の場合) で応答します。

2番目のタイプを受信すると、宛先に到達したことがわかり、より高いTTLのプローブの送信を停止します。しないこの決定は、応答の送信元のアドレスに基づいて行われます。ターゲット アドレスから Time-Exceeded メッセージを受信した場合、増加し続けます。

つまり、トレースは、ルータが Time-Exceeded で応答し、ターゲット アドレスがそのソースであることを示しています。これはおそらく、ルータが NAT を実行しており、ターゲット アドレスがその背後にあるプライベート アドレスに対応するパブリック アドレスであることを意味します。

しかし奇妙なのは、最終的な回答が違うアドレス。通常、応答はルーターを経由して返されるので、プライベート IP はパブリック IP に変換されます。この場合、アドレスとして 10.1.1.10 の 2 つの行が表示されます。

どうやらこの場合、10.1.1.9 から元のマシンへのパスは NAT ルーターを通過する必要がないため、アドレスは変換されません。非対称ルーティングは、多くの場合、異常なtraceroute結果をもたらします。この場合、すべてのマシンは 10.0.0.0/8 プライベート アドレス空間内にあるため、直接パスが利用可能であることはまったく驚くことではありません。

答え2

ルーターの設定がわからないため、確実なことはわかりませんが、考えられる原因としては、宛先 NAT (別名リバース NAT、別名ポート転送)、またはこの場合はむしろ公開ホストが挙げられます。

10.1.1.10ルータは転送/DNATに設定できる。すべてプライベート IP からのリクエストを含め、10.1.1.9 ホスト (= 公開ホスト) に送信されます。パブリック IP からは、実際の宛先 10.1.1.9 が NAT ルーターによって隠されているため、最後のホップが 2 つ表示されます。この場合、リクエストのみが DNAT され、応答がそのまま転送される可能性があります。

また、10.1.1.10 と 10.1.1.9 の両方が他の場所で DNAT され、後者がデフォルトの返信アドレスである可能性もあります。これにより、RTT が大幅に増加する理由が説明できます。

答え3

時間には注意してください。Traceroute は、スイッチまたはルーターに「処理中です」という応答を送信元に返すように要求するパケットを送信します。ただし、このパケットは、TTL と応答時間の設定、間のデバイスの設定、ルーティング テーブル、およびネットワークのトポロジに応じて、さまざまな順序で宛先 (この例ではマシン) に到達する可能性があります。

関連情報