こんにちは！大規模データセンターのネットワークオペレーションセンター（NOC）で、日々モニターの海と格闘しているシニアエンジニアです。
ネットワークの向こう側で通信が途絶えたとき、あるいは「なんだか最近、あのサーバーへのアクセスが遅いな……」と感じたとき、あなたなら最初にどのコマンドを叩きますか？多くのエンジニアは、まず ping で生存確認をし、そしてその次に traceroute（Windowsなら tracert）のスイッチを入れるはずです。
「パケットが今、世界のどこを旅していて、どのルーターで足止めを食らっているのか」を丸裸にしてくれる traceroute ですが、その裏側で何が起きているか、考えたことはありますか？
今回は、この traceroute の心臓部である「TTLの制御」と「UDP/ICMPの使い分け」について、身近な例えを交えながら、泥臭い現場の視点も交えて一緒に紐解いていきましょう！難しい用語が出てきても「一歩ずつ理解していきましょうね！」と丁寧に解説するので、安心してついてきてくださいね。
—
1. 宛先までの「迷子の手紙」を想像してみよう
まずは、パケットの旅を私たちの身近な世界に置き換えてみましょう。そうですね、手紙を送るシチュエーションを思い浮かべてみてください。
あなたが東京から、遠く離れたロンドンの友人に手紙を出しました。この手紙には、宛先として友人の住所が書かれています。もし、郵便配達の仕組みがただ「宛先に向かって真っ直ぐ放り投げる」だけだったらどうでしょう？ もし途中の運送会社（中継地点）で手紙が迷子になったとき、どこで止まってしまったのか、誰も分からなくなってしまいますよね。
そこで、賢い配達員（traceroute）はこう考えました。
「そうだ、今回は『ここまで来たら一度私に連絡しなさい』という有効期限付きの特別なスタンプを押した手紙を、1通ずつ順番に送ってみよう！」
この「有効期限付きスタンプ」こそが、ネットワークの世界でいう TTL（Time To Live：生存時間） という仕組みなんです。
—
2. TTL（Time To Live）の正体と、ルーターの冷たいお返事
TTLは、もともとは「パケットがインターネットの海を永遠にさまよい続けて、無限ループに陥るのを防ぐため」の寿命カウンターです。ルーターを1台通過するごとに、このTTLの数値が「1」ずつ減らされていきます。そして、もしTTLが「0」になってしまったら、そのパケットは容赦なくその場でゴミ箱行き（破棄）になってしまいます。
ここで、traceroute はこの仕組みを「逆手にとって」利用します。次のようなズルい（？いや、素晴らしい！）作戦を立てるのです。
1. 1通目の手紙： TTLをあえて 1 にして送り出します。
→ すぐ隣の最初のルーターに届いた時点でTTLが 0 になり、そのルーターは手紙を破棄します。そして「おい、お前の手紙、寿命が切れたぞ！」という怒りの返事（ICMP Time Exceededというエラーメッセージ）をあなたに送り返してきます。これで「1台目のルーターの住所（IPアドレス）」が判明します！
2. 2通目の手紙： 今度はTTLを 2 にして送り出します。
→ 1台目のルーターは無事に通過しますが、2台目のルーターに届いた瞬間にTTLが 0 になり、また同じように「寿命です！」というエラーメッセージが返ってきます。これで「2台目のルーターの住所」が判明します！
3. 3通目の手紙： TTLを 3 にして……。
このように、TTLの値を 1、2、3……と1つずつ増やしていくことで、宛先にたどり着くまでの経路上にあるルーターの顔（IPアドレス）を、手前から順番に暴いていくことができるのです。これが traceroute の基本原理です。
—
3. なぜパケットの種類（UDPとICMP）を使い分けるの？
さて、ここで少し疑問が湧きませんか？「ルーターにわざわざ『寿命だよ』と言わせるために、最初に送り出す手紙の中身は、いったい何なの？」という疑問です。
実は、OSやツールによって、この「最初に送り出す手紙（プローブパケット）」の正体が異なります。主に使われるのは以下の2つです。
- UDPパケットを使う方式（おもにLinuxやmacOSのデフォルト）
- ICMPパケットを使う方式（おもにWindowsの
tracertや、ネットワーク診断ツールのオプション）
それぞれの特徴を、現場のエンジニア目線で分かりやすく見ていきましょう。
UDPパケットを使う場合（Linux / macOSのデフォルト）
LinuxやmacOSで traceroute 8.8.8.8 と叩くと、裏側では 「誰も聞いていないような、わざと変なポート番号（例: 33434番など）」宛てのUDPパケット が発射されます。
中継ルーターたちは「寿命切れです！」と返してくれますが、運良く（あるいは意図通りに）パケットが最終目的地（宛先サーバー）まで届いたとしましょう。すると、最終目的地のサーバーはこう思います。
- 「あれ？ 私のところにUDPパケットが届いたけど、こんな変なポート番号宛て、誰も待ち受けてないよ……？」
困った最終目的地のサーバーは、送信元（あなた）に対して、「ICMP Port Unreachable（ポート到達不能）」 というエラーメッセージを返します。
traceroute は、この「ポート到達不能」というメッセージを受け取った瞬間に、「おっ、ついに目的地（ゴール）に到着したな！」と判断して、旅を終了するのです。
ICMPパケットを使う場合（Windowsの tracert や、traceroute -I など）
一方で、Windowsの tracert や、ネットワーク機器のデバッグでよく使われる手法では、最初から ICMP（ECHO REQUEST、いわゆるpingの仲間） パケットが使われます。
この場合、最終目的地にたどり着くと、サーバーは通常のpingと同じように「ICMP Echo Reply（お返し）」を返してくれます。
「あ、ちゃんとゴールから返事が返ってきたぞ！」ということで、こちらも無事にゴール判定が下されます。
> 💡 実務でのワンポイントアドバイス
> 現代のインターネットでは、セキュリティ上の理由（DDoS攻撃対策やファイアウォールのポリシー）から、UDPパケットや特定のICMPパケットを途中のルーターやファイアウォールが「無視（ドロップ）」するように設定しているケースが多々あります。
> そのため、標準の traceroute だと途中の行がすべて * * * （タイムアウト）になってしまうことがあります。そんなときは、ファイアウォールを抜けやすいICMPやTCPのパケットを使うモード（例: traceroute -I や traceroute -T）に切り替えるのが、現場でのベテランの定石テクニックです！
—
4. 実際にコマンドを叩いて、パケットの足音を聞いてみよう
百聞は一見にしかず。実際に手元の環境で、traceroute がどのように動いているのかを確認してみましょう。
以下のコードは、Linux環境で実際に traceroute を実行する際の例と、その挙動をイメージするための簡単なPythonスクリプト（概念実証用）です。
Linuxでの実行例
# GoogleのパブリックDNS（8.8.8.8）までの経路を調査する
# -n オプションをつけると、DNSの逆引きを省略してIPアドレスだけを高速に表示してくれます（現場では必須のテクニック！）
$ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.1.1 1.234 ms 1.112 ms 0.985 ms # 自宅のWi-Fiルーター（TTL=1で応答）
2 10.0.0.1 5.432 ms 5.121 ms 4.980 ms # プロバイダのゲートウェイ（TTL=2で応答）
3 192.0.2.1 12.345 ms 11.890 ms 12.011 ms # 途中のキャリア網のルーター（TTL=3で応答）
... (中略) ...
10 8.8.8.8 15.678 ms 15.432 ms 15.555 ms # ゴール！GoogleのDNSサーバー（到着完了）Pythonで理解する！TTL制御のイメージコード
「TTLをインクリメントしながらパケットを投げる」という仕組みを、Pythonのソケットプログラミングの概念で非常にシンプルに表現すると、次のようなイメージになります。（※実際にはrawソケットや権限が必要ですが、あくまで概念の理解用です）
import socket
import time
def simple_traceroute_concept(dest_ip):
dest_port = 33434 # tracerouteがよく使うダミーポート
max_ttl = 30
print(f"経路探索開始: 宛先 {dest_ip}\n")
for ttl in range(1, max_ttl + 1):
# 1. ソケットを作成し、TTL（IP_TTLソケットオプション）を動的に設定する
send_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
send_socket.setsockopt(socket.IPPROTO_IP, socket.IP_TTL, ttl)
# 2. 宛先に向かってダミーのUDPパケットを送信
start_time = time.time()
try:
send_socket.sendto(b"Hello Traceroute!", (dest_ip, dest_port))
# 3. 応答（ICMP Time Exceeded または Port Unreachable）を待つ受信用ソケットの処理
# ※実際のコードでは受信処理のバインドやタイムアウト設定が必要になります
print(f"TTL {ttl:2d}: パケット送信成功 (寿命: {ttl})")
except socket.error as e:
print(f"TTL {ttl:2d}: エラー発生 -> {e}")
finally:
send_socket.close()
# 簡易的なループ脱出条件（実際にはゴールからの返事を受け取ったらブレイクします）
if ttl >= 5:
print("\n... (ここでゴールに到達したと仮定して終了します)")
break
# 実行例の呼び出し（ダベート用IP）
# simple_traceroute_concept("8.8.8.8")—
5. おわりに：ネットワークの「景色」を楽しもう
いかがでしたでしょうか？ traceroute という一見ただの文字が並ぶ黒い画面の裏側では、「あえて寿命の切れた手紙を送り、中継地点からの『寿命だよ！』という怒りや呆れの声を集めて地図を描く」 という、とてもユニークで泥臭いドラマが繰り広げられているのです。
ネットワークのトラブルシューティングに王道なし、と言われます。しかし、パケットが今どこを走り、どのルーターで立ち往生しているのかを頭の中でスラスラと思い描けるようになると、障害調査は「不安な謎解き」から「ワクワクする冒険」へと変わっていきます。
ぜひ今度ネットワークの調子が悪くなったときは、traceroute （または tracert）をそっと立ち上げ、パケットたちの小さな旅路に思いを馳せてみてくださいね。それでは、また次回のNOC技術コラムでお会いしましょう！
コメント