FWログとパケットキャプチャを突き合わせて原因特定する方法

「FWログでは許可されているのに通信できない」
「パケットは流れているが、アプリが動かない」

このようなトラブルでは、FWログ単体や パケットキャプチャ単体を見ても原因に辿り着けません。

本記事では、FWログとパケットキャプチャを突き合わせて 通信障害の原因を論理的に特定するための、実務向け手順を解説します。

なぜ「突き合わせ」が必要なのか

• FWログ：ポリシー判断の結果
• パケット：実際に流れた事実

FWは「通したつもり」でも、通信は成立していないケースが多く存在します。

全体像：原因特定の基本フロー

1. 通信仕様（IP / Port / Protocol）を整理
2. FWログで許可・遮断を確認
3. パケットでSYN/ACKや再送を確認
4. 差分から原因を特定

STEP① まず通信仕様を明確にする

整理すべき項目

• 送信元IP / 送信先IP
• 送信元ポート / 宛先ポート
• TCP or UDP

ここが曖昧だと、ログもパケットも正しく見られません。

STEP② FWログで確認するポイント

最低限確認する項目

• 許可 or 拒否
• 適用ポリシー名
• セッションID
• NAT有無

FWログ例（概念）

ALLOW TCP src=10.1.1.10 dst=10.2.2.20 sport=52344 dport=443
policy=WEB-ALLOW

この時点では「FWは通した」ことしか分かりません。

STEP③ パケットキャプチャで確認するポイント

最低限見るべきTCP挙動

• SYNが送信されているか
• SYN-ACKが返ってきているか
• ACKで確立しているか

tcpdump例

tcpdump -i eth0 host 10.2.2.20 and tcp port 443

ケース① FWログは許可、SYN-ACKが返らない

観測結果

• FWログ：ALLOW
• パケット：SYNのみ

原因候補

• サーバ側FW・OS FWで遮断
• サーバ未起動／ポート未Listen

判断ポイント

FWより先で止まっていることが分かります。

ケース② SYN-ACKは返るがACKが返らない

観測結果

SYN → SYN-ACK → （ACKなし）

FWログの特徴

• 片方向のみセッション成立

原因

• 戻り通信の経路不一致
• 非対称ルーティング
• NAT設定不整合

ケース③ パケットは正常だがFWがセッションを切断

観測結果

• RST送信
• 短時間でセッション消失

FWログ例

SESSION TIMEOUT

原因

• FWセッションタイムアウトが短すぎる
• 長時間通信アプリとの相性問題

ケース④ NAT環境でIPが一致しない

よくある誤解

• FWログのIPとパケットのIPが違う

理由

FWログはNAT後、パケットはNAT前を見ていることがあります。

対処

• NAT変換前後のIP対応表を確認

突き合わせ時の実務チェックリスト

• FWログの時刻とパケット時刻は一致しているか
• 同一通信を見ているか（ポート番号）
• NAT有無を考慮しているか
• 往復通信を確認しているか

やってはいけないNG対応

• FWルールを闇雲に広げる
• any-anyで一時回避
• パケットを見ずに「FWのせい」と決めつける

これらは再発・事故の温床になります。

まとめ

• FWログは「判断結果」、パケットは「事実」
• 片方だけでは原因特定できない
• 突き合わせることで論理的に切り分け可能

FWログ × パケットキャプチャを使いこなせるようになると、 ネットワーク障害対応の精度が一段上がります。