FortiGateセッションテーブルの見方｜diagnose sys session listで追跡

2026年4月10日2026年5月16日

トラブルシューティング

FortiGateセッションテーブルの仕組みと通信追跡フロー — FortiGate セッションテーブルの通信追跡フロー

👷 現場での体験談

ある日、「特定のサーバーへの通信が突然できなくなった」と連絡が入りました。FortiGateのログを見ても明確なドロップ記録はなく、設定も変更していない。そこでセッションテーブルを確認すると、古いセッションが残り続けており、新規接続を妨げていることが判明しました。

目次 [ close ]

FortiGateセッションテーブルに関するよくある質問（FAQ）

セッションテーブルを使ったトラブルシューティング実例

セッションテーブルの確認技術は、ネットワークトラブルシューティングの最重要スキルの一つです。適切なコマンドを使えば、問題の原因を数分で特定できます。

セッションテーブルとは？FortiGateにおける役割

セッションテーブルとは？FortiGateの通信管理の仕組み

セッションテーブルは、ファイアウォールが現在処理している通信状態を管理する内部データベースです。FortiGateでは、すべての通信（TCP、UDP、ICMP等）がセッションとして記録され、パケットの送受信状態や関連ポリシー情報が保持されます。

ステートフルインスペクション型ファイアウォールであるFortiGateは、このセッションテーブルを参照して、戻りパケットが正当な通信の一部かを判断します。そのため、セッションテーブルを正しく理解することが、トラブルシューティングの鍵となります。

あわせて読みたい関連記事

まとめ：セッションテーブル活用のポイント

セッションテーブルの構成要素を以下にまとめます。

項目	内容
送信元IP/ポート	通信を開始したクライアントのIPアドレスとポート番号
宛先IP/ポート	接続先サーバーのIPアドレスとサービスポート
プロトコル	TCP/UDP/ICMPなどの通信プロトコル
セッション状態	ESTABLISHED、SYN_SENT、CLOSEDなどのTCP状態
適用ポリシーID	この通信を許可したファイアウォールポリシー番号
タイムアウト値	セッションが自動削除されるまでの残り時間

セッションテーブルの確認コマンドと出力の読み方

diagnose sys session listコマンドの実践

FortiGateでセッションテーブルを確認する基本コマンドが「diagnose sys session list」です。このコマンドはCLIから実行し、現在アクティブなすべてのセッション情報を表示します。

基本的な実行例と出力の読み方

FG200D # diagnose sys session list

session info: proto=6 proto_state=01 duration=123 expire=3597 timeout=3600
src=192.168.1.100:52341 dst=203.0.113.50:443 vd=root policy_id=10
total session 1542

この出力から読み取れる重要情報は以下の通りです。

図1: セッション情報の構成要素

接続時間

85%

ポリシー情報

75%

送受信アドレス

90%

プロトコル状態

70%

⚠ 注意

proto=6はTCP、proto=17はUDPを意味します。proto_stateは内部状態コードで、01はESTABLISHED状態を示します。この数値は機種やバージョンで変わる場合があるため、状態確認には注意が必要です。

セッションフィルタで効率的に通信を絞り込む

セッションのフィルタリングテクニック

実運用環境では数千から数万のセッションが存在するため、全セッションを表示すると画面が流れてしまいます。diagnose sys sessionコマンドには強力なフィルタリングオプションがあり、目的のセッションだけを抽出できます。

実務で頻用するフィルタコマンド

送信元IPで絞り込み

diagnose sys session filter src 192.168.1.100
diagnose sys session list

宛先ポートで絞り込み

diagnose sys session filter dport 443
diagnose sys session list

ポリシーIDで絞り込み

diagnose sys session filter policy 10
diagnose sys session list

セッションのクリアとタイムアウト制御

フィルタのクリア

diagnose sys session filter clear

複数条件を組み合わせることも可能です。例えば、特定の送信元から特定の宛先ポートへの通信だけを表示したい場合は、フィルタを連続して設定します。

diagnose sys session filter src 192.168.1.100
diagnose sys session filter dport 443
diagnose sys session list

セッション数管理とリソース枯渇対策

FortiGateには機種ごとに最大セッション数の上限があり、この制限に達すると新規接続が拒否されます。セッション数を監視し、異常な増加を検知することは、安定運用の重要ポイントです。

現在のセッション数確認方法

FG200D # get sys performance status

CPU states: 8% user 3% system 0% nice 89% idle
Memory: 2048MB total, 1024MB used (50%)
Average network usage: 150 / 250 kbps in 1 minute
Sessions: 8542 active (21354 max)

この例では、最大21354セッションのうち8542が使用中で、まだ余裕がある状態です。セッション使用率が80%を超えると警戒が必要です。

図2: セッション枯渇の主な原因

DDoS攻撃

88%

アプリ不具合

65%

タイムアウト設定

52%

NAT制限

38%

セッション枯渇時の対処法をまとめます。

対処法	実施内容	効果
異常セッション特定	送信元IP別にセッション数を集計	攻撃元の特定
タイムアウト調整	TCPタイムアウト値を短縮	古いセッション削除促進
セッションクリア	特定条件でセッション強制削除	即座にリソース解放
ポリシー最適化	不要ポリシーの削除・統合	処理効率向上

通信障害時のセッション確認フロー

「通信ができない」という障害報告を受けた際、セッションテーブルを確認することで、問題がFortiGate内部にあるのか、それとも外部要因かを切り分けられます。以下、実践的なトラブルシューティング手順を解説します。

トラブルシューティングの実践ステップ

セッションの存在確認

送信元IPと宛先IP/ポートでフィルタし、セッションが作成されているか確認。セッションがなければポリシー設定を疑う。

セッション状態の確認

proto_stateが01（ESTABLISHED）でなく、SYN_SENTのまま残っている場合、サーバー側に到達していない可能性が高い。

適用ポリシーIDの確認

policy_idから実際に適用されたポリシーを特定し、セキュリティプロファイル設定を確認。意図しないポリシーが適用されていないかチェック。

パケットキャプチャ併用

セッションは存在するが通信が不安定な場合、diagnose sniffer packetでパケット詳細を解析し、ドロップやリトライの有無を確認。

FG200D # diagnose sys session filter src 192.168.1.100
FG200D # diagnose sys session filter dst 203.0.113.50
FG200D # diagnose sys session list

→セッションが表示されない場合
  ポリシー設定やルーティングに問題がある可能性大

→セッションがSYN_SENTのままの場合
  宛先サーバーが応答していない可能性大

セッションクリアコマンドの正しい使い方

古いセッションや異常なセッションを強制的に削除する場合、diagnose sys session clearコマンドを使用します。ただし、このコマンドは既存の通信を切断するため、慎重に実行する必要があります。

セッションクリアの実行例

特定IPのセッションのみクリア
FG200D # diagnose sys session filter src 192.168.1.100
FG200D # diagnose sys session clear

特定ポリシーのセッションをクリア
FG200D # diagnose sys session filter policy 15
FG200D # diagnose sys session clear

全セッションクリア（緊急時のみ）
FG200D # diagnose sys session clear

⚠ 注意

全セッションクリアは全ユーザーの通信が一時的に切断されます。実行前に必ず影響範囲を確認し、メンテナンス時間内に実施してください。フィルタを設定すれば影響を最小限にできます。

セッションクリアが必要な典型的シナリオを整理します。

シナリオ	理由と効果
ポリシー変更後	古いポリシーで確立したセッションには新設定が反映されないため、クリアして再接続させる
NAT設定変更後	既存セッションは古いNATエントリを保持しているため、通信異常が発生する可能性
セッション枯渇	異常なセッションを削除してリソースを即座に解放し、正常な通信を復旧
ルーティング変更後	既存セッションは古いルート情報を参照しており、戻りパケットが正しく処理されない

まとめ

FortiGateのセッションテーブル確認は、ネットワークトラブルシューティングの基本中の基本です。diagnose sys sessionコマンドを使いこなすことで、障害の原因特定時間を大幅に短縮できます。特にフィルタ機能を活用すれば、数万セッションの中から問題のある通信だけをピンポイントで抽出可能です。

セッションテーブルにはすべての通信状態が記録され、ポリシーIDや接続時間などの詳細情報を含む
diagnose sys session filterで送信元、宛先、ポート、ポリシーIDなど多様な条件でフィルタリング可能
セッション枯渇時は異常なIPを特定してクリアし、タイムアウト値の見直しも検討する

FortiGateセッションテーブルに関するよくある質問（FAQ）

Q. セッションテーブルがいっぱいになるとどうなる？

セッションテーブルが上限に達すると、新規セッションが確立できなくなり、通信障害が発生します。「get system performance status」でセッション使用率を確認し、80%を超えたらアラート設定を検討しましょう。不要なセッションのタイムアウト短縮やセッション上限の引き上げ（機種による）で対処できます。

Q. セッションを手動でクリアする方法は？

「diagnose sys session clear」で全セッションをクリアできますが、本番環境では通信断が発生するため注意が必要です。特定のセッションだけクリアする場合は、先にフィルタを設定してから「diagnose sys session clear」を実行します。例えば「diagnose sys session filter dst 10.0.0.1」→「diagnose sys session clear」で特定宛先のセッションのみ削除できます。

Q. proto_stateの数値はどう読めばいい？

TCPセッションのproto_stateは2桁の数値で、左がクライアント側、右がサーバー側の状態を示します。01がESTABLISHED、02がSYN_SENT、11がFIN_WAIT等を意味します。通常の通信確立後は01になるめ、それ以外の値が長時間続く場合は通信異常の可能性があります。

Q. セッションテーブルとdebug flowの使い分けは？

セッションテーブル（diagnose sys session list）は「現在確立中の通信」を確認するのに使います。一方、debug flow（diagnose debug flow）は「パケットがFortiGate内でどう処理されているか」をリアルタイムで追跡する機能です。通信できない原因を調べるときはdebug flow、通信中のセッション状態を確認するときはセッションテーブルが適しています。