tracerouteの色々

by ejharaldseid



インターネットのネットワークに多少なりと興味がある方なら、指定の目的地までの経路探索をしてくれる、みんな大好きtracerouteコマンド。
そんなtracerouteの色々をメモしておきます。

tracerouteの仕組み

既に多くの解説サイトがあるので、そちらに譲りますw

tracerouteはTTLを1ずつ増やしながらパケットを送信することで、経路情報を取得する。 TTLとはパケットの生存期間を表し、ルータを1つ経由することに1ずつ減算される。 ルータはTTLが2以上のパケットが届いた場合、TTLの値を1だけ小さくし次のルータへ転送する。 TTLが1のパケットが届いた場合、届いたパケットを破棄しICMP time exceededパケットを送信者に返す。

tracerouteはまず、TTLを1にセットしたパケットを送信する。最初のルータに届いた時点でTTLがゼロになり、ICMP time exceededメッセージが戻ってくる。このメッセージの送信元アドレスを見れば、最初のルータのIPアドレスがわかる。次にTTLを2にセットして送信すると、今度は2番目のルータからICMP time exceededが戻ってくる。以降、TTLを3、4・・・と増やしていく事で、順にルータのIPアドレスを得る事ができる。

実際には、以上の作業を3回繰り返して行い、応答までの時間を表示する。 経由しているルータが応答せずタイムアウトが発生した場合は、*マークを表示する。 tracerouteで得られる経路情報は往路のみである。反対側からの経路も同じとは限らない。

traceroute - Wikipedia


他、下記のサイトには、図説があったりして、なかなかわかりやすいです。

ICMP/UDP/TCPを使う

↑の仕組みの説明は、ICMPパケットを利用した方法ですが、tracerouteの実装によっては、他にもUDPTCPGREを使ったものなどがあります。
Windows(tracert)では、ICMPパケットが使われていますが、Unix/Linux(traceroute)では、デフォルトでUDPパケットが利用されます。


尚、Ubuntu(Linux)で、tracerouteコマンドのmanを読むと、以下のような指定です。

-I     Use ICMP ECHO for probes

-T     Use TCP SYN for probes

-U     Use UDP to particular destination port for tracerouting  (instead  of
       increasing the port per each probe). Default port is 53 (dns).

-M method
       Use specified method for traceroute operations.  Default  traditional
       udp  method  has name default, icmp (-I) and tcp (-T) have names icmp
       and tcp respectively.
       Method-specific options can be passed  by  -O .   Most  methods  have
       their simple shortcuts, (-I means -M icmp, etc).

※ TCPを利用するケースについては、tcptracerouteというコマンドもある。


あれっ、tracerouteコマンド実行したけど、ほとんど「*」が表示されて経路がよく分からない!(><) ...といった場合でも違うプロトコルを利用すれば、ひょっとしたら好ましい調査結果となるかもしれません。

その場合は、Linuxとかだと↑のオプション通りですが、

$ traceroute -I (IPアドレス or FQDN)

見たいな感じで、オプションを付けて実行してみてください。

UDPを使用するtracerouteは、ポート番号が定まらないためパケットフィルタリングを行っているネットワークでは利用が難しい面があり、特にファイアウォールがある場合は問題になりやすい。 また、最終的な宛先ノードにパケットが到達した際、ICMP Echo requestの場合は単にICMP Echo replyが返されるだけだが、UDPの場合は、たまたまそのポート番号が使われていた等で、期待した動作にならない事がある。

traceroute - Wikipedia

Wikipediaでも上記のような記載がありますが、プロトコルによっては途中経路でパケットを落とされるケースも多く、インターネットで外部に公開しているサービスに向けて調べる場合、多くのケースでTCPパケット(ex. HTTP)が利用されていることが多いので、TCPを使うのが、最も成功率の高い調べ方かもしれません


ちなみに、書籍「インターネットのカタチ」によると、tracerouteの利用可能状況を2008年に調査した論文では、アメリカの計測サーバから、アメリカ国内の2000台のルータに対してtracerouteを実行した結果、ICMPでは全試行の84.5%が経路探索に成功し8.2%が途中経路に「*」が出力、UDPでは全試行の69.2%が経路探索に成功し23.3%が途中経路に「*」が出力という結果だったそうです。UDPよりはICMPを使ったほうが成功率が高い可能性がある、ということですね。

注意点: 戻りの経路について

tracerouteコマンドで調べられるのは、あくまで行きの経路だけです。戻りの経路については、行きとは異なっている可能性があります。

ところで、これまた書籍「インターネットのカタチ」によると、ワシントン大学のreverse traceroute (revtr) プロジェクトが、対象のホストから自ホストまでの経路、つまり戻りの経路を探索できる仕組みを考案しているとのことです。
reverse tracerouteは、tracerouteのようにコマンドではなくて、下記のWebサイトでサービスとして試験提供されています。


ちなみに、"はてなブログ"で試させてもらったところ、以下のような結果がメールで送られてきました。

Thanks for trying our reverse traceroute tool! The resulting data follows:

reverse traceroute from ec2-54-249-30-47.ap-northeast-1.compute.amazonaws.com (54.249.30.47) back to planetlab1.sfc.wide.ad.jp (203.178.143.10)
 0  ec2-54-249-30-47.ap-northeast-1.compute.amazonaws.com (54.249.30.47) 19.332001 ms 18.938 ms 19.063999 ms             dst
 1   (27.0.0.204) 20.726 ms 20.691999 ms 20.736 ms                                                                       sym
 2   (27.0.0.25) 11.235 ms 11.233 ms 10.985 ms                                                                           rr
 3   (27.0.0.23) 10.604 ms 10.575 ms 10.551 ms                                                                           rr
 4  jc-osa302.kddnet.ad.jp (113.157.227.248) 10.684 ms 11.055 ms 11.007 ms                                               -rr
 5  obpjbb205.int-gw.kddi.ne.jp (118.155.199.252) 13.906 ms 13.946 ms 13.917 ms                                          -rr
 6  obpjbb206.int-gw.kddi.ne.jp (118.155.199.253) 10.589 ms 10.68 ms 10.609 ms                                           rr
 7  ix-osa207.kddnet.ad.jp (118.155.199.78) 10.246 ms 10.181 ms 23.028999 ms                                             ts
 8  ge-0-1-v2.cisco3.dojima.wide.ad.jp (203.178.138.47) 10.053 ms 9.749 ms 9.772 ms                                      ts
 9  ve-3761.cisco2.dojima.wide.ad.jp (203.178.136.110) 10.058 ms 9.927 ms 9.932 ms                                       rr
10  ve-51.cisco2.notemachi.wide.ad.jp (203.178.141.142) 1.633 ms 1.644 ms 1.74 ms                                        rr
11  ve-51.foundry6.otemachi.wide.ad.jp (203.178.141.141) 1.688 ms 1.626 ms 1.51 ms                                       tr
12  ve-42.foundry4.nezu.wide.ad.jp (203.178.136.66) 1.49 ms 1.568 ms 2.666 ms                                            -tr
13  ve-46.juniper2.fujisawa.wide.ad.jp (203.178.136.94) 1.85 ms 0.779 ms 0.347 ms                                        -tr
14  ve100.alaxala3.sfc.fujisawa.wide.ad.jp (203.178.137.87) 0.504 ms 0.465 ms 0.474 ms                                   -tr
15  planetlab1.sfc.wide.ad.jp (203.178.143.10) 0.045 ms 0.031 ms 0.03 ms                                                 -tr

The rightmost columns explains how we determined a path. A dash prefix indicates that this hop was determined from the same segment as an earlier hop.
dst - This hop is the destination or the destination's uplink.
sym - We had to assume this hop was symmetric to the forward traceroute in order to generate the path. Note that we always assume that hop1, the destination's uplink, is symmetric, in order to avoid excess probing of endhosts. This assumption will generally be true for endhosts.
tr - This hop was determined from an intersection with a known traceroute.
rr - We used the Record Route option of the Internet Protocol to find this hop.
ts - We used the Timestamp option of the Internet Protocol to find this hop.

See here for more details on the different methods. 

関連ツール

mtr

mtrは、宛先を指定すると、経路を探索し、それぞれの中継地点のルーターに対して、一定間隔でpingを実行し、RTT値やパケロスの統計を記録します。
経路上のネットワークが不調の疑いがある場合など、しばらくmtrを実行して経過観察を行うことで、問題点の切り分けができます。

$ mtr (IPアドレス or ホスト名)

で、実行した結果は、以下のような感じで出力され続けます。

                         My traceroute  [v0.71]
(0.0.0.0)                                       Thu Aug 15 23:56:43 2013
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%  Last   Avg  Best  Wrst StDev
 1. 10.200.xx.xx                      0.0%   0.2   0.3   0.2   0.5   0.1
 2. 10.202.xx.xx                      0.0%   0.5   0.6   0.4   0.8   0.1
 3. 10.202.yy.yy                      0.0%   0.3   0.7   0.2   2.7   0.7
 4. 10.202.zz.zz                      0.0%   1.0   1.0   0.8   1.5   0.2
 5. ???
 6. 27.0.0.135                        0.0%   2.7   2.7   2.6   2.9   0.1
 7. 27.0.0.147                        0.0%   2.9   3.0   2.9   3.0   0.1
 8. ec2-x-x-x-x.ap-northeast-1.compu  0.0%   2.5   2.8   2.5   2.9   0.1


もうちょっと書こうかと思ったのですが、今日は、いったんここまで。(また別エントリで)
それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

インターネットのカタチ―もろさが織り成す粘り強い世界―

インターネットのカタチ―もろさが織り成す粘り強い世界―