問題提起: ネットワークの「遅さ」があなたのせいではない場合
午前2時、電話が鳴り続ける。監視システムがアラートを発している: サービスXが接続障害に見舞われている。ユーザーは「遅すぎて使い物にならない」と不満を漏らす。あなたの心臓は高鳴る。次々と疑問が頭をよぎる: ファイアウォールがブロックしているのか？設定ミスか？それとも光ケーブルが断線したのか？
根本原因を迅速に特定するために、私は常にtracerouteとmtrを思い浮かべます。これら2つのネットワークツールは、パケットの経路を示すだけでなく、各ホップでの接続品質も明らかにします。
以前、困難なネットワークトラブルシューティングを行った時のことを今でも鮮明に覚えています。断続的なパケットロスがピーク時のみ発生するという問題でした。pingの結果は不安定で不明瞭。mtrを使って数時間（例えば17時から22時まで）継続的に監視した結果、中間ホップでパケットがドロップしていることを正確に突き止めました。最終的に、問題のあるサービスプロバイダーを特定できたのです。その時、私はmtrがパケットがどこへ行くかだけでなく、どのように行くかも教えてくれることに気づきました。
核心概念: パケットはどこへ行き、その品質はどうか？
Traceroute: パケット経路の探偵
tracerouteは古典的なネットワークユーティリティで、あなたのマシンからターゲットサーバーまでのIPパケットの経路を追跡するのに役立ちます。Time To Live (TTL) 値を増加させながら、特別なパケット（通常は大きなポート番号を持つUDP、またはICMP ECHO REQUEST）を送信することで機能します。
- TTLとは？ パケットがルーター（ホップ）を通過するたびに、TTL値は1減少します。TTLが0になると、ルーターはそのパケットを破棄し、送信元マシンにICMP「Time Exceeded」メッセージを返します。
- 動作方法:
tracerouteはまずTTL=1のパケットを送信します。最初のルーターはTTLを0に減らし、パケットを破棄して「Time Exceeded」メッセージを送信します。tracerouteはこのルーターのアドレスを記録します。次に、TTL=2の2番目のパケットを送信し、2番目のルーターが同様に応答します。このプロセスは、パケットが宛先に到達するまで繰り返され、その時点で宛先はICMP Port UnreachableまたはICMP Echo Replyで応答します。
tracerouteの結果は、パケットが通過するルーター（ホップ）のリストと、各ホップからの応答時間（Round Trip Time – RTT）です。これにより、いくつの「中継点」があり、どの区間で遅延が高いかを特定できます。
MTR (My Traceroute): 詳細な統計情報付きの連続「Traceroute」
tracerouteが一瞬のパケット経路の「スナップショット」しか提供しないのに対し、mtrはpingとtracerouteを組み合わせたものです。これは、接続品質に関する動的で継続的なビューを提供し、定期的にパケットを送信し、各ホップのリアルタイムで更新される統計情報を表示します。
mtrは、パケットロスや遅延の問題を特定する必要がある場合に私が信頼して使用するツールです。特に、次のような重要なパラメータを通じて、パケットが経路のどこで問題に遭遇しているかを明確に示します。
- Loss%: そのホップで失われたパケットのパーセンテージ。
- Snt: そのホップに送信されたパケットの数。
- Last/Avg/Best/Wrst: 最終、平均、最良、最悪のパケット応答時間（遅延）。
- StDev: 遅延の標準偏差。そのホップでの接続の安定性を示します。
mtrを使用すると、特定のルーターで発生するパケットロスや、特定のネットワークセグメントで急激に遅延が増加するなどの問題を容易に検出できます。これは、tracerouteを1回実行するだけでは難しいことです。
実践詳細: ネットワークの「解剖」に取り掛かる
始める前に、これらのツールがあなたのLinuxシステムにインストールされていることを確認してください。ほとんどのディストリビューションでは、リポジトリで利用可能です。
mtrのインストール (未インストールのS場合)
# Debian/Ubuntuの場合
sudo apt update
sudo apt install mtr-tiny
# CentOS/RHELの場合
sudo yum install mtr -y
Tracerouteの基本的な使い方
google.comへの経路を確認したいと仮定します:
traceroute google.com
以下のような結果が表示されます:
traceroute to google.com (142.250.187.142), 30 hops max, 60 byte packets
1 _gateway (192.168.1.1) 0.370 ms 0.315 ms 0.287 ms
2 172.16.0.1 (172.16.0.1) 1.921 ms 1.910 ms 1.905 ms
3 10.0.0.1 (10.0.0.1) 2.520 ms 2.515 ms 2.508 ms
4 118.69.XXX.XXX (118.69.XXX.XXX) 6.321 ms 6.310 ms 6.305 ms
5 103.232.XXX.XXX (103.232.XXX.XXX) 7.892 ms 7.881 ms 7.875 ms
6 72.14.215.196 (72.14.215.196) 8.234 ms 8.225 ms 8.219 ms
7 142.251.52.129 (142.251.52.129) 8.210 ms 8.199 ms 8.192 ms
8 hcm02s09-in-f14.1e100.net (142.250.187.142) 8.185 ms 8.174 ms 8.168 ms
解説:
- 各行は経路上の「ホップ」（ルーター）を示します。
- 最初の数字（
1、2、3…）はホップの順番です。 _gateway、172.16.0.1…はルーターのホスト名またはIPアドレスです。- 続く3つの
ms値は、そのホップに送信された3つのテストパケットの応答時間（Round Trip Time – RTT）です。* * *が表示されている場合、そのホップからの応答がなかったことを意味します（ファイアウォールがブロックしているか、ルーターがICMPに応答しない可能性があります）。
Tracerouteの便利なオプション
-I: UDPの代わりにICMP ECHO REQUESTを使用します（pingと同様）。UDPがブロックされている場合に役立ちます。
traceroute -I google.com
-n: ドメイン名をIPアドレスに解決しません。これにより、結果がより速く返されます。
traceroute -n google.com
-m [max_hops]: 最大ホップ数を制限します。
traceroute -m 10 google.com
MTRを使って通信品質を「検査」する
より継続的で詳細な情報を得るには、mtrを使用します。デフォルトでは、mtrはインタラクティブモードで実行されます。
mtr google.com
mtrのインターフェースは以下のようになります（継続的に更新されます）:
