動画と記事で学ぶ / 試験・障害対応
PingのEcho RequestとEcho Replyは別々の経路を通ります。192.0.2.10と203.0.113.10の例で往路・復路を比較し、非対称経路、ステートフルFW、NATによる片方向通信の切り分け方を解説します。
ここからは、記事でゆっくり確かめましょう。図や操作の例を見ながら、気になるところから読み進めてください。
Pingが失敗したとき、行きの経路ばかり調べていませんか。Pingは要求を送るだけで終わらず、相手の返信を受け取って初めて成功します。
要求は相手のIPを宛先に進み、返信は自分のIPを宛先に戻ります。それぞれが別々に経路を選ぶため、往路が通っても復路が通るとは限りません。一つのPingを二本の矢印に分けると、確認する場所が見えてきます。
要求と返信は、別の宛先を持つパケット
PCからサーバーへのEcho Requestは、サーバーが宛先です。サーバーからPCへのEcho Replyは、PCが宛先。途中のルーターは、それぞれの宛先に合う経路を使います。
往路で使った道を返信も記憶してたどる、という動作ではありません。両側の経路表が違えば、別の装置を通って戻ることもあります。
| パケット | 送信元 → 宛先 | 確認する経路 |
|---|---|---|
| Echo Request | PC 172.28.31.10 → サーバー 172.28.53.10 | PC側GWと各中継機器の172.28.53.10宛 |
| Echo Reply | サーバー 172.28.53.10 → PC 172.28.31.10 | サーバー側GWと各中継機器の172.28.31.10宛 |
Ping失敗の表示から分かるのは、時間内に期待した返信を受け取れなかったことです。要求が届かなかったのか、返信が戻らなかったのかは、追加の確認が必要です。
戻り側は、元の送信元IPへの経路を調べる
往路はサーバー宛、復路はPC宛の経路を検索します。デフォルトルートだけでなく、より長いプレフィックスの経路、PBR、VRFなどが選択に影響します。
ルーターからPingする場合は送信元も確認してください。出力インターフェースのIPが使われると、PCからの通信とは違う戻り先になります。
- 送信元で172.28.53.10宛の選択経路と送信元IPを記録する。
- 宛先で172.28.31.10宛の選択経路とデフォルトGWを記録する。
- FW-A／FW-Bの両方で、同じICMP識別子・時刻の要求と応答を確認する。
- NATがある場合は、変換前後のアドレスと、戻りが同じ変換状態へ一致するか確認する。
「ルーターのPingは成功、PCは失敗」というときは、同じ宛先でも送信元と入口が違う可能性があります。対象端末のIPへの戻り経路と、ACLの条件を確認します。
経路が一行あるだけで安心せず、その宛先で実際に選ばれる経路を調べます。同じVRFと送信元をそろえることも必要です。
要求がどこまで届き、返信がどこから出たかを追う
送信元で条件を固定し、試験時刻を記録します。次にサーバー側や途中の取得点で、要求が見えるかを確認します。要求が届いているなら、相手が返信を作ったかへ調査を進めます。
相手で返信が出ているなら、復路のルーターやFWを追います。両方向を一度に「通らない」とまとめるより、正常な区間を確定できます。
# Linux source指定
ping -I 172.28.31.10 -c 5 172.28.53.10
ip route get 172.28.53.10 from 172.28.31.10
# Cisco例
show ip route 172.28.53.10
show ip route 172.28.31.10172.28.53.10 from 172.28.31.10 via 172.28.31.1 dev eth0 src 172.28.31.10
64 bytes from 172.28.53.10: icmp_seq=1 ttl=60 time=8.4 msキャプチャに要求がない場合でも、取得NICやフィルターが正しいかを確認します。観測漏れと、本当に届いていない状態は別です。
表や出力は説明用の例です。実際の記録では、取得装置、インターフェース、方向、時刻を添え、一つのPingの要求と返信を対応させます。
FWとNATは、返信が同じ状態へ一致するかを見る
ステートフルFWは接続の状態を管理します。要求がFW-Aを通り、返信が状態を持たないFW-Bへ入ると、許可した接続の返信として認識できない場合があります。
NATでも、返信が変換情報へ一致することが必要です。行きで変換したIP・識別情報と、返信先を確認します。戻りが別の装置へ流れる構成は、状態共有の条件も調べます。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 要求だけ見える | 宛先ホスト/FWで応答生成不可 | ホストファイアウォール、アドレス、サービス |
| 応答が宛先側から出るが届かない | 戻り経路・ACL・NAT | 逆方向の各ホップ |
| 片方のFWだけセッションなし | 非対称経路 | ルーティング優先度とECMP |
| 送信元指定で結果が変わる | VRF/インターフェースごとの経路差 | 実サービスと同じ送信元で再試験 |
すべてのFWが同じ動作ではありません。単純なステートレスACLなら、返信パケットもその方向のルールで照合します。FWのセッション確認とACLの行評価を混同しないようにします。
NATの前後でIPが変わるなら、キャプチャのフィルターも合わせます。変換前のIPだけで外側を探すと、返信がないように見えることがあります。
Pingの復旧と、業務通信の復旧を分けて確認する
経路や制御を直したら、同じ端末・同じ送信元でPingを再試験します。要求と返信が往復することを確かめ、変更前後の経路やログを残します。
Ping成功はICMPの往復を示します。WebのTCPやTLSが正常か、業務アプリが使えるかは別に確認します。最初に失敗していた操作まで戻って試してください。
往路と復路は同じでなくてもよい。ただし、両方に必要な経路と制御があり、FW・NATの状態に合う必要があります。
図に行きと戻りを別の色で描くところから始めると、「要求はここまで確認できた」「返信はこの先が未確認」と説明しやすくなります。
動画・筆者の投稿で補足する
文章と図で流れをつかんだら、関連する動画も参考にしてください。画面の表示や操作は、機種・ソフトウェアの版によって異なる場合があります。
確認に使った公式資料
このテーマを続けて学ぶ
