ネットワークの向こう側で何かが起きているとき、私たちの相棒といえば ping や traceroute ですよね。
「あれ、なんでこのサーバーに繋がらないんだろう？」
「どこでパケットが迷子になっているんだ？」
そんな疑問を持ったとき、真っ先に黒い画面（ターミナル）を開いて traceroute を叩くのがインフラエンジニアの日常です。NOC（ネットワークオペレーションセンター）で数々の夜を越えてきた私も、障害の切り分けでは毎日のようにこのコマンドにお世話になっています。
さて、ここで一つ、ネットワーク初学者の皆さんが必ずと言っていいほどハマる「謎」があります。
それは、「同じ traceroute なのに、Windowsで実行するのと、LinuxやMac（UNIX系）で実行するのとで、挙動や結果が変わることがある」 という現象です。
「えっ、同じ宛先を調べているのに、どうして結果が違うの？」
「ファイアウォールを越えられる時と越えられない時があるのはなぜ？」
今回は、そんな疑問をスッキリ解決するために、ICMP版とUDP版の traceroute の違いを、身近な例えを交えながら一緒に紐解いていきましょう！一歩ずつ理解していけば、決して難しい話ではありませんよ。
—
郵便配達でイメージする traceroute の基本
まずは、traceroute がそもそもどんな仕組みで動いているのかを、私たちが普段使っている「郵便配達」に例えて考えてみましょう。
あなたが遠く離れた友達に手紙（パケット）を送りたいとします。でも、その手紙がどのルートを通って友達の元に届くのか、途中のどんな中継局（ルーター）を通るのかは分かりません。そこで、あなたは郵便局員にお願いして、こんな手紙を出しました。
「この手紙には、あえて『寿命（有効期限）』を 1 に設定しておきます。最初の郵便局に着いたら、そこで寿命が切れて『宛先に届きませんでした』というお返事を私に送り返してください！」
郵便局員はルール通り、最初の交差点（ルーターA）に手紙を持っていきました。すると、手紙の寿命が 1 なので、ルーターAで「あ、これ以上運べないな」となり、あなたに向けて「ここまでしか運べませんでしたよ」というお返事を送ります。これが 1 段目のルーターの特定です。
次に、あなたは寿命を 2 にして同じ手紙を出します。今度はルーターAを通り抜け、次の交差点（ルーターB）で寿命が切れるため、ルーターBからお返事が返ってきます。
これを 3、4…と寿命を1つずつ増やしながら繰り返すことで、目的地までの道順をすべて暴き出す。これが traceroute の魔法のタネなんです。
—[PR]—
大規模ネットワークの障害対応、その泥臭い現場のリアルを覗いてみませんか？NOCエンジニアが実践するトラブルシューティングの極意をメルマガで配信中！
—————
—
なぜOSによってやり方が違うの？（ICMP版 vs UDP版）
さて、ここからが本題です。先ほどの郵便配達の手紙（パケット）ですが、「中身をどう書くか」 に派閥があるんです。それが、OSごとの違いを生み出しています。
1. UNIX系（Linux / macOS）のやり方：UDPを使う流儀
LinuxやMacなどのUNIX系OSは、デフォルトでは UDPというプロロコル を使って traceroute を行います。
やり方はこうです。
「普段は使わないような、すっごく高いポート番号（宛先ポート：33434番など）に向けて、適当なデータを詰め込んだ手紙を送ろう。宛先のサーバーはそんなポート番号聞いてないから、着いたときに『そんなポート空いてないよ！』っていうエラー（Port Unreachable）を返してくれるはずだ。それを利用してゴール判定をしよう」
つまり、途中のルーターからは「寿命切れです」というお返事をもらい、最終目的地のサーバーからは「ポートが存在しません」というお返事をもらうことで、「おっ、ゴールに到着したな！」と判断するわけです。
2. Windowsのやり方：ICMPを使う流儀
一方、私たちが普段よく使うWindowsの tracert コマンドは、ICMP（Internet Control Message Protocol） という、ネットワーク診断専用のプロトコルを使います。
こちらはもっとシンプルで、「あなた、生きてますか？」と確認する ping（ICMP Echo Request）と同じ仲間を使います。寿命を 1、2、3 と増やしながら、純粋に「寿命切れです（ICMP Time Exceeded）」というお返事をもらい続けることでルートを特定します。
—
ここで差が出る！ファイアウォールの「厳重なセキュリティ」
「プロロコルが違うだけで、目的地にたどり着くなら一緒じゃないの？」
そう思いますよね。実は、ここに ネットワークの門番（ファイアウォールやセキュリティアプライアンス） が絡んでくると、大きな違いが生まれるのです。
実際の企業ネットワークやクラウド環境（AWSやAzureなど）を想像してみてください。セキュリティを保つために、ルーターやファイアウォールは厳しいルールを設定しています。
- 「外部から勝手に社内のサーバーのUDPポートにアクセスされたら困るから、UDPの通信は厳しくブロックしよう！」
- 「ネットワークの故障診断に使うICMPくらいは、トラブルシューティングのために通してあげよう」
ここで、環境依存の大きな挙動の違いが生まれます。
UNIX系（UDP版）でトラブルが起きる理由
Linux環境で traceroute を実行した際、途中のファイアウォールが「なんだこの変なUDPパケットは怪しいぞ！」とブロックしてしまったり、最終目的地のサーバーがセキュリティポリシーでUDPを完全に遮断していたりすると、ゴールに到着しているはずなのに星マーク（ * * * ）が並んでしまい、先へ進めなくなってしまうことがあります。
Windows（ICMP版）がすんなり通る理由
逆に、Windowsの tracert はICMPを使っているため、ネットワーク管理者が「疎通確認用」としてICMPを許可している環境であれば、ファイアウォールの目をかいくぐって綺麗にルートが表示されることが多いのです。
「あれ？ Windowsの tracert だと通るのに、Linuxの traceroute だと途中で途切れるぞ……？」という現場のトラブルに直面したときは、大抵この「パケットの種類（UDPかICMPか）によるファイアウォールの扱い方の違い」が原因になっています。
—
現場で役立つ！実用的なコマンドと設定のテクニック
「じゃあ、LinuxでもWindowsと同じようにICMPで調べたいときはどうすればいいの？」
「逆に、ポート番号を指定して特定のアプリの通信経路を調べたいときは？」
NOCの現場でもよく使う、実用的なオプションをいくつかご紹介しましょう。環境に合わせて使い分けられるようにしておくと非常に便利です。
1. LinuxでICMP版の traceroute を実行する
Linux標準の traceroute コマンドに -I（アイ）オプションをつけると、Windowsと同じICMP（ECHO）を使ったモードに切り替えることができます。ファイアウォールに阻まれたときは、まずこれを試してみましょう。
# ICMPエコー要求を使ってtracerouteを実行する（要管理者権限や適切な権限）
sudo traceroute -I 8.8.8.8*(※日本語コメント：-I オプションを指定することで、デフォルトのUDPではなくICMPパケットを使用して経路探索を行います。セキュリティ機器にUDPをブロックされている環境で有効です。)*
2. LinuxでTCP版の traceroute を実行する（現代のインフラの救世主）
実は、ICMPやUDPすらも企業のファイアウォールに厳しくブロックされている現場はたくさんあります。そんなときの「最終兵器」が TCP版 です。Webサイトを見る通信（HTTP/HTTPS）と同じTCPのパケット（SYNパケット）を使って経路を調べます。
# Webサーバー（ポート80番）への経路をTCPで調べる
sudo traceroute -T -p 80 example.com*(※日本語コメント：-T でTCPモード、-p 80 で宛先ポートを80番（HTTP）に指定しています。Webトラフィックが通る経路と同じルートを正確にシミュレーションできるため、実務のWebトラブル切り分けで最も重宝するコマンドです。)*
—
まとめ：仕組みを知れば、もうパケット迷子にならない！
今回は、ICMP版とUDP版の traceroute の違いと、OSによる環境依存の挙動についてお話ししました。
- Windowsの
tracertは主にICMPを使う - Linux / Macの
tracerouteはデフォルトでUDPを使う - ファイアウォールやセキュリティ設定によって、どちらが通るかが変わる
- 必要に応じて
-I（ICMP）や-T（TCP）オプションを使い分けるのがプロの技！
ネットワークのトラブルシューティングは、見えないパケットの動きを頭の中でどれだけリアルに想像できるかが勝負の分かれ道です。「あ、今このパケットは途中のルーターで門番に止められているな」とスラスライメージできるようになれば、あなたも立派なネットワークエンジニアの仲間入りです。
日々の運用監視やインフラ構築の現場で、ぜひこの知識を生かしてみてくださいね。それでは、また次回のNOC技術コラムでお会いしましょう！
コメント