FW変更作業後に必ず確認すべき5項目【通信トラブルを未然に防ぐ実務チェックリスト】

FW（ファイアウォール）の設定変更は、
「投入時は問題なさそうに見えるが、後から障害になる」 代表例です。

・変更作業は完了した
・ログも deny は出ていない
・それでも「通信がおかしい」

本記事では、
FW変更後に“必ず”確認すべき5項目 を 実際の障害発生ポイント順 に解説します。

なぜFW変更は事故りやすいのか？

FWは以下を同時に制御しています。

• ポリシー（通信可否）
• NAT（アドレス変換）
• ステート（通信状態）
• タイムアウト

1行の変更が複数レイヤに影響 するため、 「設定は正しいのに通信できない」状況が頻発します。

確認①：ポリシーの「順序」と「適用ゾーン」

最も多い事故ポイント

• ルールは追加した
• だが意図した通信にヒットしていない

確認ポイント

• 想定トラフィックがどのポリシーにマッチしているか
• より上位で別ルールに捕まっていないか
• ゾーン（インターフェース）の向きが正しいか

FWは上から順に評価 します。 順序ミスは「ログが正常なのに通信不可」の温床です。

確認②：NAT（特に戻り方向）の変換状態

ありがちな誤解

「DNATを入れたから大丈夫」

実際に起きる問題

• 戻り通信がSNATされていない
• 戻りが別経路へ出ている

確認ポイント

• 行きと戻りで同一FWを通過しているか
• セッションテーブルでNAT変換が双方向成立しているか

FWログは 行きのNATしか見せない ことが多いため注意が必要です。

確認③：セッションテーブルの状態

FW変更後は必ず見る

• セッションが作られているか
• すぐ消えていないか
• 状態（SYN_SENT / ESTABLISHED 等）はどうか

読み取り例

• SYN_SENT → 戻り通信が来ていない
• ESTABLISHED → FW/NATは正常

セッションは「FWが見ている真実」 です。

確認④：タイムアウト・インスペクション設定

変更直後は問題なく見えるが…

• 数分後に切断
• 長時間通信が不安定

主な原因

• TCP/UDPタイムアウトが短い
• SSLインスペクション影響
• アプリ特性と不整合

FW変更＝通信特性も変わる ことを忘れがちです。

確認⑤：ログに「出ない通信」を想定できているか

ログに出ない代表例

• RSTによる切断
• セッションタイムアウト
• 既存セッションの影響

実務での対策

• 変更前セッションのクリア
• テスト時は新規通信で検証

「ログに出ない＝問題なし」ではありません。

FW変更後チェックリスト（現場用）

• □ 想定通信が正しいポリシーにヒットしている
• □ NATが双方向成立している
• □ セッション状態が想定通り
• □ タイムアウト・検査設定が適切
• □ 既存セッション影響を排除して検証した

まとめ

• FW変更は「入れたら終わり」ではない
• ログだけでは判断できない
• セッションを見る癖が事故を防ぐ

FW変更後に通信トラブルが起きるかどうかは、 この5項目を見たかどうか で決まります。