【入門編】 TCPベースのtracerouteとファイアウォール透過性の検証 – トラブルシューティング＆ネットワーク運用監視実践ガイド

ネットワークの「通行止め」を突破せよ！TCP tracerouteで紐解くファイアウォールの裏側

こんにちは！データセンターの片隅で、深夜のパケットの鼓動を聴きながらコーヒーを啜っているNOCエンジニアです。

ネットワークの世界に足を踏み入れたばかりの頃、先輩から「tracerouteが通らない？じゃあ次はTCPで投げてみな」と言われて、頭の中が「？」でいっぱいになった経験はありませんか？

今日は、そんな初学者の皆さんのために、「なぜ普通のpingやtracerouteだけではトラブル解決に不十分なのか」、そして「TCPを利用した経路探索がなぜ最強の武器になるのか」を、郵便配達のストーリーになぞらえて紐解いていきましょう。

—

皆さんが普段使っている traceroute（Windowsなら tracert）は、基本的には「道中のルーターに『今どこ？』と聞く」という作業を繰り返しています。

これを郵便配達に例えてみましょう。

これが標準的なtracerouteの流れです。しかし、現代のネットワークには「ファイアウォール」という名の超厳重なセキュリティゲートが立ちはだかっています。

このゲートの管理人は、不審な問い合わせ（標準的なtracerouteのパケットなど）を一切無視するよう教育されています。「知らない人からの質問には答えない」という鉄の掟ですね。だから、途中のゲートでパケットが止められ、結果が * * * と表示されてしまうわけです。

—

ここで登場するのが、TCPベースのtracerouteです。

WEBサイト（HTTP/HTTPS）を見るためのパケットは、ファイアウォールを通過するのが仕事です。もしこのパケットを止めすぎてしまうと、WEBサイト自体が見られなくなりますよね？

つまり、「WEB閲覧用のふりをして、ネットワークの経路を調査する」という作戦が有効なんです。

具体的には、80番（HTTP） や 443番（HTTPS） という、ファイアウォールが「あ、これはWEBの通信だから通してあげなきゃ」と判断するポートを狙い撃ちします。

—

Linux環境であれば、tcptraceroute というツールを使うのが定番です。インストールされていない場合は、sudo apt install tcptraceroute などでサクッと入れてしまいましょう。

実際に、特定のサーバーの443番ポートに向けて経路を辿ってみます。

# -p 443 で「443番ポート（HTTPS）宛てのパケットですよ」と偽装（擬態）します
# これにより、Web通信を通す設定のFWを突破しやすくなります
tcptraceroute example.com 443

このコマンドがやっていること：
1. 「HTTPS通信です！」という顔をしてパケットを送り出す。
2. 途中のファイアウォールは「お、Web通信か。通れ通れ」と門を開ける。
3. その裏で、本来の目的である「経路の確認」をこっそり実行する。

—

現場でよくあるのが、「特定のサーバーにはpingが通るのに、なぜかWebサイトが表示されない」というケースです。

ping：ICMPという別のプロトコルを使うため、ファイアウォールでブロックされやすい。
tcptraceroute：実際にWebサイトが使うポート（443番など）を調査するため、「ユーザーが実際にWebサイトにアクセスしたときに、どこでブロックされているか」をピンポイントで特定できる。

もし tcptraceroute を使って、途中のルーターまでは通るのに、最後のファイアウォール以降で * * * になるのであれば、それは「経路の問題」ではなく「ファイアウォールの設定ミス（ポートが空いていない）」であることが確定します。

これぞ、現場で数多くの障害を切り分けてきた「シニアの勘」をデジタル化したような手法なんです。

—

初めてのトラブルシューティングは誰だって怖いものです。でも、パケットは嘘をつきません。

「なぜ通らないのか？」と悩んだら、まずは相手（ファイアウォール）が何を許し、何を拒んでいるのかを想像してみてください。今回紹介したTCPを使った手法は、そのための強力なレンズになります。

最初はコマンドを打つ手が震えるかもしれませんが、大丈夫。まずは自分の管理下にあるサーバーで、色々なポートを試してみてください。「自分のパケットを自分でコントロールしている」という感覚が掴めれば、あなたはもう、一人前のエンジニアへの第一歩を踏み出しています。

それでは、また次回の現場でお会いしましょう！Happy Troubleshooting!