動画と記事で学ぶ / 試験・障害対応
traceroute 仕組みは、TTL、ICMP Time Exceeded、UDP/ICMP/TCP方式の関係を構成図と実際の設定・確認コマンドで追うと理解できます。実務では正常時の動作だけでなく、設定ミスや障害時に何を見るかまで押さえます。
ここからは、記事でゆっくり確かめましょう。図や操作の例を見ながら、気になるところから読み進めてください。
tracerouteやtracertの結果に「* * *」が出ると、そこが故障しているように見えるかもしれません。しかし、その先や宛先まで表示されることもあります。
このコマンドは、調査用パケットへの応答を並べて経路を調べます。すべての装置が応答するとは限らず、実際のWeb通信と同じ条件でもありません。仕組みを確認したうえで、一行の結果からどこまで判断できるかを考えましょう。
TTLを変えたプローブで、途中の応答点を調べる
TTLはルーターを通ると減る値です。TTL1のプローブを送ると最初のルーターで尽き、通常はICMP Time Exceededが返ります。TTL2なら次のルーター、というように値を増やします。
返事をした装置のIPと、応答までの時間を行に並べたものが経路の表示です。機器から構成図を一括で取得しているわけではありません。
| 送信TTL | 止まる位置 | 主な応答 |
|---|---|---|
| 1 | 最初のルーター | ICMP Time Exceeded |
| 2 | 2番目のルーター | ICMP Time Exceeded |
| 宛先まで届く値 | 宛先ホスト | ICMP Echo Reply、ICMP Port Unreachable、TCP応答など方式で異なる |
負荷分散でプローブごとに経路が変わる場合もあります。一回の出力を、すべての業務通信が常に使う固定経路として扱わないようにします。
WindowsとLinuxでは、既定のプローブが違う
WindowsのtracertはICMP Echoを使います。Linuxの一般的なtracerouteはUDPが既定で、オプションでICMPやTCPを選べる実装もあります。
FWやACLがICMPを止め、TCP443を許可する構成なら、ICMPの調査とWeb接続で結果が違っても不思議ではありません。同じ宛先でも、調べた通信の条件が違うためです。
| 環境 | 例 | プローブ |
|---|---|---|
| Windows | tracert -d 172.28.53.10 |
ICMP Echo。-dで名前解決を省略 |
| Linux | traceroute -n 172.28.53.10 |
既定のUDP。-nで名前解決を省略 |
| Linux | traceroute -I -n 172.28.53.10 |
ICMP Echo |
| Linux | traceroute -T -p 443 -n 172.28.53.10 |
TCP 443宛のプローブ |
-dや-nで名前解決を省略すると、応答IPを先に確認できます。表示が遅い原因がDNSなのか、プローブの応答待ちなのかを分ける助けになります。
オプションは利用するOSのヘルプで確認します。結果にはコマンドと方式を残し、「tracerouteを実行した」だけの記録にしないようにします。
宛先への到達と、途中の行を分けて読む
まず最後に宛先からの応答があるかを見ます。次に、応答が途切れる場所、繰り返すIP、普段と違う経路を確認します。正常時の出力があれば、同じ送信元と方式で比較します。
同じ行に複数の時間があるのは、複数のプローブを送った結果です。応答IPが分かれる場合は、負荷分散なども考えます。
# Windows
tracert -d 172.28.53.10
# Linux: UDP / ICMP / TCP 443
traceroute -n 172.28.53.10
traceroute -I -n 172.28.53.10
traceroute -T -p 443 -n 172.28.53.101 172.28.31.1 1.1 ms 0.9 ms 1.0 ms
2 172.28.42.1 4.2 ms 4.0 ms 4.1 ms
3 172.28.53.10 8.5 ms 8.3 ms 8.4 ms途中で時間が大きくても、その先が小さいなら、その装置自身のICMP応答処理が遅い可能性があります。その値だけで、業務パケットも同じだけ遅れるとは言えません。
表示IPも、装置が応答を返すために使ったアドレスです。構成図のリンクIPと違うときは、どの装置の応答かを資料と照合します。
アスタリスクは「時間内に返事がなかった」
途中の一行だけ「*」で、その先が表示されるなら、そこでパケット転送が完全に止まっているとは考えにくくなります。ICMPの制限、応答しない仕様、戻り経路などを確認します。
以後すべて「*」なら、転送障害も候補ですが、宛先まで応答を返さない設定の可能性もあります。宛先のサービスへ別の方法で接続して比べます。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 途中だけ * * * | ICMP rate limit・フィルター・無応答 | 後続ホップと宛先が応答するか |
| 全方式が同じホップで停止 | 経路・ACL・戻り経路 | 両端の経路とポリシーログ |
| 名前表示だけ遅い | reverse DNS | -d/-nで再実行 |
| 毎回経路が変わる | ECMP・動的ルーティング | 複数回取得し正常時と比較 |
要求が届く経路と、ICMPの通知が戻る経路は別です。送信元側の出力だけでは、そのどちらで失敗したかを確定できません。
FWログ、両側の経路、キャプチャなどを同じ試験時刻で合わせると、どこまで届き、どこから返信したかを絞れます。
結果は、送信元・方式・時刻と一緒に残す
調査には、送信元IP、宛先、コマンド、プローブ方式、時刻、出力を残します。VRFや送信元指定を使った場合は、その条件も記録します。
tracerouteの成功と、業務アプリの成功は別です。WebならTCP接続、TLS、HTTP応答も確認し、調査結果がどの段階を示すかを明確にします。
「三行目で止まった」より、「ICMPの応答は三行目まで。TCP443は成功した」と書くほうが、結果を正しく伝えられます。
仕組みが分かると、アスタリスクを見てもすぐ故障と決めなくなります。正常時と同条件で比べ、追加で何を調べるかを選んでみてください。
動画・筆者の投稿で補足する
文章と図で流れをつかんだら、関連する動画も参考にしてください。画面の表示や操作は、機種・ソフトウェアの版によって異なる場合があります。
確認に使った公式資料
このテーマを続けて学ぶ
