【入門編】 UDPベースのtraceroute(主にUnix/Linux標準)の動作と宛先ポートの仕様 – トラブルシューティング＆ネットワーク運用監視実践ガイド

こんにちは！大規模データセンターの現場で、日々泣き笑いしながらネットワークの番人をしているシニアエンジニアです。数え切れないほどの夜間障害を乗り越えてきましたが、いつの時代もネットワークトラブルの基本は「今、パケットはどこで迷子になっているのか？」を見つけ出すことに尽きます。

ネットワークの世界に足を踏み入れたばかりの頃、「なんだか繋がらない！」という壁にぶつかった経験はありませんか？そんなとき、私たちが真っ先に相棒として呼び出すのが traceroute（Windowsなら tracert）という魔法のコマンドです。

今回は、Linuxなどの標準的な環境で使われている「UDPベースの traceroute」が、裏側でどんなドラマを繰り広げているのかを、身近な例えを交えながら一緒に紐解いていきましょう。難しい専門用語はいったん脇に置いて、一歩ずつリラックスして進んでいきましょうね！

—

1. パケットの「迷子の旅」を追跡するtracerouteの正体

皆さんは、遠く離れた友人に荷物を送るとき、ちゃんと届いているか「追跡番号（トラッキング）」で調べたことがありますよね。「いま中継地点のハブ局にいるな」とか「もうすぐ配達だな」というのが手に取るようにわかります。

ネットワークの世界でも全く同じことが起きているんです。あなたのパソコンから目的地（サーバーなど）へ向かうデータ（パケット）は、途中でいくつものルーターという「中継地点」をバトンタッチしながら旅をしています。途中で通信がプツリと途絶えたとき、「一体どこで荷物が止まってしまったのか？」を突き止めてくれるのが traceroute です。

実は、Windowsの tracert は主に「ICMP（Pingの仲間）」という仕組みを使っているのですが、UNIXやLinuxの標準的な traceroute は、ちょっとユニークな 「UDP」 というプロトコルを主役にしてこの追跡を行っています。

—

2. 郵便配達で例えるUDP tracerouteの仕組み

「UDPって、なんだかゲームの通信とかで聞くけど…？」「届いたか確認しないわがままな通信って聞いたけど、どうやって追跡するの？」と思われるかもしれませんね。

ここで、ちょっと面白い郵便配達のストーリーに例えてみましょう。

1. 謎のイタズラ郵便の作成
あなたは、絶対に誰も受け取らないような「使われていない変な番号（例: 33434番）」宛ての荷物を作ります。これが、tracerouteが飛ばす「UDPパケット」です。
2. 「寿命」という名のスタンプ
その荷物に「中継できるルーターは『1個』だけね」という特別な有効期限（TTL: Time to Live）のスタンプを押してポストに投函します。
3. 1つ目のルーターの反応
あなたの家を出た荷物は、最初に出会ったルーターに届きます。ルーターは荷物のスタンプを見て、「おっと、もう寿命が切れそうだぞ。これ以上運べないな」と判断します。そして、あなたの元へ「すみません、寿命が切れて返却します！」という手紙（ICMP Time Exceeded）を送り返してくれます。これで「1つ目のルーターの住所」が判明します！
4. 徐々に距離を伸ばす
次は「寿命2個分」のスタンプを押して同じ荷物を送ります。すると、2つ目のルーターで同じことが起き、2つ目の住所がわかります。
5. 目的地への到着と「受取拒否」
これを繰り返して、ついに目的地のサーバーまで荷物が届きました！しかし、サーバー側からすると「えっ、こんな変な番号（33434番）の荷物、ウチのアプリは知らないよ！」となります。困ったサーバーは、あなたに向けて「そんなポート番号は開いてないよ！（ICMP Port Unreachable）」というエラーの返事を送ります。

このエラーを受け取ったあなたのパソコンは、「やった！目的地までパケットがちゃんと到達したぞ！」と確信し、ここで追跡の旅を終了するのです。

すごくよくできた、巧妙な仕組みだと思いませんか？

—

3. 実践！Linuxでtracerouteを動かしてみよう

理屈が分かったところで、実際にLinuxの端末（ターミナル）を開いて、その挙動を覗いてみましょう。

例えば、パブリックDNSである 8.8.8.8 に向かって traceroute を実行してみます。

# GoogleのパブリックDNSに向かってtracerouteを実行します
$ traceroute 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  gateway (192.168.1.1)  2.123 ms  1.987 ms  1.854 ms
 2  10.0.0.1 (10.0.0.1)  5.432 ms  5.120 ms  4.980 ms
 3  softbank-isp-router.net (203.0.113.1)  12.345 ms  11.987 ms  12.112 ms
 ...
 10  dns.google (8.8.8.8)  15.123 ms  14.987 ms  15.050 ms

画面にずらっと並んだ数字やIPアドレスが見えますね。
左端の 1, 2, 3… が先ほどお話しした「寿命（TTL）のカウント」です。最初は1から始まり、ルーターを越えるごとに1つずつ増えていきます。

それぞれの行にある ms（ミリ秒）という単位は、パケットがそのルーターまで行って帰ってくるまでの「往復時間（RTT）」を表しています。ネットワークの遅延（重さ）を調べるときにも、この数値が非常に重要な手がかりになります。

ちょっとマニアックな実務の裏技

Linuxの traceroute はデフォルトでUDPを使いますが、ファイアウォール（セキュリティの壁）が厳重な環境では、UDPパケットが途中でブロックされてしまい、星マーク（ * * * ）ばかりが表示されて先に進めないことがあります。

そんなときは、実務の現場ではよく次のようなオプションを組み合わせて回避します。

# TCPのSYNパケットを使ってtracerouteを実行する（ポート80番などをターゲットにする）
$ sudo traceroute -T -p 80 8.8.8.8

# もしくは、お馴染みのICMP（Pingと同じプロトコル）を使う
$ sudo traceroute -I 8.8.8.8

-T や -I といったオプションを使うことで、通信のプロトコルを変更できます。「UDPがダメならTCPやICMPで試してみよう」という、百戦錬磨のエンジニアたちが現場でよく使う定番のテクニックです。

—

まとめ

今回は、UDPベースの traceroute が持つ宛先ポートの仕様と、私たちが目的地にたどり着くまでのドラマチックな仕組みについて解説しました。

tracerouteは、わざと届かない高いUDPポート番号へパケットを投げる。
途中のルーターからは「寿命切れ（Time Exceeded）」の返事をもらい、中継地点を特定する。
最終目的地からは「そんなポート知らないよ（Port Unreachable）」という返事をもらって、旅の終わりを検知する。

一見すると複雑に見えるネットワークの診断ツールも、裏側で行われていること優しく分解してあげると、とてもロマンチックでシンプルな仕組みで動いていることがわかりますよね。

日々の運用監視やトラブルシューティングで「あれ？」と思ったときは、ぜひ今回の仕組みを思い出してみてください。きっと思い描いたパケットたちの旅路が、頭の中で鮮やかに見えてくるはずです。

それでは、また次回の技術コラムでお会いしましょう！快適なネットワークライフを！