ルーティングは正しいのに戻り通信が来ない時の切り分け（非対称通信の落とし穴）

URLをコピーしました！

ネットワークトラブルで特に厄介なのが、

「ルーティングは合っているのに、なぜか通信が成立しない」

というケースです。

pingの送信は出ている
ルートも正しい
tcpdumpでも送信は見える

それでも戻り通信が来ない。

この状況は、単なるルーティング問題ではありません。

本記事では、

戻り通信が消える代表パターン
レイヤ別の切り分け手順
「正しいのにダメ」を抜け出す判断軸

を実務視点で整理します。

まず結論：戻り通信は「経路」ではなく「状態」で落ちる

多くの人が最初に確認するのはルーティングですが、

戻り通信が来ない原因の多くは「経路以外」

にあります。

FW/NATのセッション
非対称ルーティング
送信元IPの変化

ここを疑わないと、永遠にハマります。

切り分けの基本方針

以下の順で考えると迷いません。

戻り通信は「どこまで」来ているか
途中で「誰が」捨てているか
なぜ「正しく見えているのに」捨てられるか

① 非対称ルーティングを疑う

最頻出パターンです。

行き：

Client → FW-A → Router → Server

戻り：

Server → Router → FW-B → Client

このように経路がズレると、

FWのセッションが成立せず破棄されます。

確認ポイント

行きと戻りで通過FWが同じか
tcpdumpで双方向が見えるか

対処

PBR（Policy Based Routing）の見直し
FW経路の対称化

② FW/NATセッションで落ちていないか

FWやNATは

「通信の流れ」を状態として管理

しています。

以下がズレると、戻り通信は即破棄されます。

送信元IPが想定と違う
ポート番号が変わる
セッションタイムアウト

確認ポイント

NAT変換前後のIP/Port
セッションテーブルに存在するか

③ 送信元IPが途中で変わっていないか

ルーティングが正しくても、

送信元IPが変わると戻り先がズレます。

典型例

SNAT/DNATの誤設定
ロードバランサ配下

確認方法

tcpdump -n host <server_ip>

行きと戻りでIPが一致しているかを確認します。

④ ルーティング「テーブルは正しい」が「実際の選択」が違う

以下の影響で、

想定外の経路が選ばれる

ことがあります。

metricの差
ECMP
ポリシールーティング

確認

ip route get <dest_ip>

実際に選ばれる経路を見るのが重要です。

⑤ L7で返していないケースもある

ここまで問題がなければ、

アプリケーション側が返していない

可能性もあります。

Listenしていない
アクセス制御
アプリ内部エラー

tcpdumpでSYN-ACKが出ているかが判断材料です。

切り分け早見フロー

tcpdumpで戻り通信は存在するか
FWセッションは張られているか
経路は対称か
IPは変わっていないか

この順で確認すれば、

「ルーティングは正しいのに…」から抜け出せます。

まとめ

戻り通信は「経路」より「状態」で落ちる
非対称ルーティングが最頻出
FW/NATの視点を必ず入れる

戻り通信が見えた瞬間、

問題はもう半分解決しています。