【入門編】 tracerouteのTCPオプションを用いた高度な経路診断とフィルタリング回避 – トラブルシューティング＆ネットワーク運用監視実践ガイド

こんにちは！現場の最前線でパケットの群れと格闘し続けて早◯十年、NOC（ネットワークオペレーションセンター）のシニアエンジニア兼、技術ブログ主筆の「テック長（おさ）」です。

深夜のデータセンター、静まり返ったサーバーラックの間で、たった一つのパケットがどこで迷子になったのかを探し当てる……。そんなスリル満点（？）な日々を過ごしています。

新人エンジニアの皆さんが最初に覚える診断コマンドといえば、やはり ping や traceroute でしょう。でも、実務に入るとこんな壁にぶつかりませんか？

「相手のWebサイトは見えているのに、traceroute を打つと途中から * * *（タイムアウト）ばかりで何も見えない……」

これ、実は現代のネットワーク運用では「あるある」なんです。今日は、そんな鉄壁の防御をスマートにすり抜け、真の経路を浮き彫りにする「TCP traceroute」という魔法のテクニックを、世界一分かりやすく紐解いていきましょう！

—

1. なぜ、普通の「traceroute」は無視されるのか？

まずは、私たちが普段使っている標準的な traceroute の仕組みを、「郵便配達」に例えて考えてみましょう。

標準的な traceroute（LinuxならUDP、WindowsならICMP）は、いわば「中身のないハガキ」を次々に送っているようなものです。

1. 1件目の家（ルーター）に届いたら「ここで終わり！」と言ってもらう。
2. 2件目の家に届いたら「ここで終わり！」と言ってもらう。

こうして順番に返事をもらうことで、目的地までの道順を記録していきます。しかし、最近のインターネットの世界は物騒です。多くのルーターやファイアウォール（門番）は、こう考えています。

「なんだ、この中身のないハガキ（UDP/ICMP）は？怪しいから無視して捨ててしまえ！」

これが、画面が * * * で埋め尽くされる正体です。門番が「業務に関係ないパケット」を門前払いしているんですね。

—

2. 救世主「TCP SYN」パケットの登場

そこで、ベテランエンジニアが使うのが「TCP traceroute」です。

これは、ハガキを送るのではなく、「正式なお客さんのフリをして挨拶に行く」という手法です。具体的には、Web通信などで使われる TCP SYN という「接続お願いします！」という挨拶パケットを使います。

門番（ファイアウォール）も、Webサイトを公開している以上、「ポート80番（HTTP）」や「ポート443番（HTTPS）」への挨拶を無視するわけにはいきません。これを利用して、経路を無理やり聞き出すわけです。

「寿命（TTL）」をあえて短く設定するトリック

ここで重要になるのが TTL（Time To Live）という仕組みです。これを「パケットが持っているお菓子の数」だと思ってください。

パケットがルーターを1つ通過するたびに、お菓子を1個消費します。
お菓子が0個になったルーターは、「ごめん、もうお菓子がないからこれ以上先には運べないよ！」というエラーメッセージ（ICMP Time Exceeded）を送り主に返してくれます。

TCP tracerouteは、この「お菓子をわざと少なく持たせた、正規の挨拶パケット」を順番に送ることで、門番に怪しまれずに各ルーターからの返事をもらうテクニックなのです。

—

3. 実践！TCP tracerouteを使ってみよう

それでは、実際にコマンドを叩いてみましょう。Linux環境（UbuntuやCentOSなど）で最も一般的に使われる方法を紹介します。

基本のコマンド例

まずは、標準的な traceroute に -T オプション（TCPを使うという合図）を付けて実行します。

# -T : TCPパケットを使用する
# -p 443 : Webサイトでよく使われるHTTPSのポート（443番）を指定する
# www.google.com : 診断したい宛先
sudo traceroute -T -p 443 www.google.com

# ※ TCP tracerouteは生のパケットを生成するため、通常は「sudo（管理者権限）」が必要です。

出力結果の読み解き方

コマンドを実行すると、以下のような結果が返ってきます（数値は例です）。

traceroute to www.google.com (172.217.161.68), 30 hops max, 60 byte packets
 1  gateway (192.168.1.1)  0.521 ms  0.412 ms  0.388 ms
 2  10.0.0.1 (10.0.0.1)  1.234 ms  1.112 ms  1.050 ms
 ...
10  nrt12s22-in-f4.1e100.net (172.217.161.68) [open]  5.231 ms  5.110 ms  5.055 ms

注目すべきは、最後のホップに [open] と表示されたり、ちゃんと目的地まで到達している点です。もし普通の traceroute で * * * となっていた場所が、この方法でスッキリ見えるようになったら、「途中のファイアウォールがUDPを止めていたんだな」と判断できるわけです。

—

4. 現場で役立つ「もう一つの武器」：tcptraceroute

標準の traceroute コマンドが入っていない環境や、より詳細な制御をしたい場合は、その名もズバリ tcptraceroute という専用ツールが便利です。

インストールと実行

# Ubuntu/Debianの場合
sudo apt update && sudo apt install tcptraceroute -y

# 実行例：宛先の80番ポート（HTTP）に対して経路確認
sudo tcptraceroute www.example.com 80

このツールは、まさに「TCPで経路診断をすること」に特化しているため、非常に安定して結果を返してくれます。我々NOCの人間が、本番環境のネットワーク疎通を確認する際の「1本目の刀」として愛用するツールの一つです。

—

5. トラブルシューティングでの活用シナリオ

「TCP tracerouteができるようになった。で、結局何がわかるの？」という疑問にお答えしましょう。現場ではこんな風に使い分けます。

1. 「Webブラウザでは開けるのに、pingが通らない」時

→ traceroute -T -p 443 を実行。
→ 経路が最後まで見えれば「ネットワーク経路は正常。単に相手がICMP（ping）を拒否しているだけ」と安心できます。

2. 「特定のサービス（例えばデータベース）だけ繋がらない」時

→ traceroute -T -p 3306（MySQLの場合）を実行。
→ 途中のルーターで止まったら「そこでアクセス制限（ACL）がかかっている」ことが一発で分かります。

—

まとめ：一歩ずつ、パケットの気持ちになろう

ネットワークのトラブルシューティングは、一見難しそうに見えますが、実は「パケットがどこまで歩いて、どこで通行止めを食らったか」を確認するだけのシンプルな作業です。

普通の traceroute は、ハガキを投げるようなもの。
TCP traceroute は、正規のスーツを着て挨拶に行くようなもの。

この違いを理解して使い分けるだけで、あなたの診断能力は劇的に向上します。「繋がらない！」と慌てる前に、まずは -T オプションを付けて、パケットにスーツを着せて送り出してみてください。

ネットワークの世界は、目には見えませんが、コマンド一つでその姿を雄弁に語ってくれます。一歩ずつ、楽しみながら理解を深めていきましょう！

それでは、また次の「現場の知恵」でお会いしましょう。ハッピー・パケット・ハンティング！