NetworkエンジニアでTracerouteは必ず一度は(いや何千回も)使ったことのあるTracerouteですが実は詳しくその中身について調べたことはありませんでした。
この記事ではTracerouteの機能にについてまとめいきたいと思います。
Tracerouteとは
Tracerouteをググってみると、ざっくりとまとめると
「ICMPを使って宛先のホストまでのネットワーク経路やその障害を調べることの出来るツール」
といった検索結果が返ってきます。
もう少し具体的に言うと、宛先ホストに対してTTLを1から順に数字を上げていきながらTTLが0となるRouterから「ICMP Time Exceeded」を受信することによって通信経路を調べていくことができる機能です。
というのが、私が理解していたTracerouteといった感じです。
より具体的にTracerouteを知るために実際にTracerouteの中身を見ていきたいと思います。
自宅のクライアント(mac)からGoogle DNS(8.8.8.8)へTraceroute
私の作業用MacBookからGoogleのDNSサーバである8.8.8.8にTracerouteを打ってみます。
最初の2Hopは私の自宅のNetworkとなります。3Hop目からTransixを介して最終的(7Hop目)にはdns.googleに到達していることが確認できます。
Wiresharkにてパケットキャプチャをとってみます。
パケットキャプチャの内容は勿論Tracerouteの実結果と同じものとなります。
しかし、よく見直すとMacからはUDPで8.8.8.8に対してパケットを送信していることがわかります。そうなんです、Tracerouteは必ずしもICMPで送信するとは限っていないのです。
これを踏まえて改めてググってみると、
・Windows : ICMP(Echo)を利用
・Linux(macOS、Ciscoを含む) : UDPを利用
となっているようです。
ですので、Windows端末からTraceroute(実際にはTracert)を行った結果とLinux系の端末からTracerouteを行った結果では利用するプロトコルが異なるため結果が変わることがあり得るのです。
そして、もう一つ気づくのは同じパケットを3回ずつ送信しているのです。
・TTL=1のパケットを3回送信
・ICMP(Time-to-live exceeded)を3回受信
・TTL=2のパケットを3回送信
といった感じです。
ですので、CLIでTracerouteを行った際にレスポンスタイムがそれぞれで3つ表示されていたのです。(これは皆さん常識ですかね?)
また、6Hop目はTracerouteの結果は*となっていますが、パケットキャプチャではICMPのレスが来ていないことも分かります。これは、6Hop目のRouterがICMPを送信しない設定になっていることがわかります。
ちなみに、TTLの数を上げていくのと共に送信先のUDP Portも1ずつ上げて送信しているようです。
NAT越しでも何故ICMPは戻ってくるのか?
ここであることに疑問があがってきます。私の自宅の環境は当たり前ですがNATを介してIPv4のInternetへの通信を行っているのですが、何故UDPで送信したパケットに対して戻りのICMPパケットがNATを超えて戻ってきているのでしょうか?
Windows系のICMPを使って送信したパケットの戻りに関してであれば、何となく分からなくもないのですが、行きのUDPパケットと戻りのICMPパケットは(通信上は)全く別のものとなります。
WiresharkのICMPパケットの中身の詳細を見てみると、
ICMPヘッダの中にTime-to-live exceededとなったオリジナルのパケットの情報が埋め込まれているのがわかります。(そう言えば数十年前にそんな事を習ったような。。)
このICMPパケットを送信する理由となったパケットはUDPのSource Portは47448でDestination Portが33435であることが分かります。
NATを行っているRouter(もしくはFirewall)はICMP Time-to-lice exceededを受信するとICMPヘッダの中にあるオリジナルのパケット情報からNATテーブルを参照し、元の端末に通信を届けるといった処理を行っているということです。
まとめ
これまで何気なくTracerouteを使っていましたが、改めてパケットキャプチャを取得してみると色々なことがわかりました。
1. WindowsはICMP(Echo)をLinux系はUDPを使ってパケットを送信
2. TTLを1にセットし3回パケットを送信
3-1. ICMP Time-to-live Exceededを受信すると、経路上のRouterは正しく動作しているとしてTTLを1上げてパケットを再送信
3-2. パケットのレスポンスがない場合は通信経路が遮断している可能性があるが、該当ルータが(IPを隠蔽するために)ICMPのレスを行わない場合もあるのでTTLを1上げて次の経路を検索する。
4. WindowsであればEcho Replyが、Linux系ではICMP Port Unreachableが届くとターゲットホストへの通信が成功したとしてTracerouteを終了する