ある日、「特定のサーバーへの通信が突然できなくなった」と連絡が入りました。FortiGateのログを見ても明確なドロップ記録はなく、設定も変更していない。そこでセッションテーブルを確認すると、古いセッションが残り続けており、新規接続を妨げていることが判明しました。
セッションテーブルの確認技術は、ネットワークトラブルシューティングの最重要スキルの一つです。適切なコマンドを使えば、問題の原因を数分で特定できます。
セッションテーブルは、ファイアウォールが現在処理している通信状態を管理する内部データベースです。FortiGateでは、すべての通信（TCP、UDP、ICMP等）がセッションとして記録され、パケットの送受信状態や関連ポリシー情報が保持されます。
ステートフルインスペクション型ファイアウォールであるFortiGateは、このセッションテーブルを参照して、戻りパケットが正当な通信の一部かを判断します。そのため、セッションテーブルを正しく理解することが、トラブルシューティングの鍵となります。
セッションテーブルの構成要素を以下にまとめます。
| 項目 | 内容 |
|---|---|
| 送信元IP/ポート | 通信を開始したクライアントのIPアドレスとポート番号 |
| 宛先IP/ポート | 接続先サーバーのIPアドレスとサービスポート |
| プロトコル | TCP/UDP/ICMPなどの通信プロトコル |
| セッション状態 | ESTABLISHED、SYN_SENT、CLOSEDなどのTCP状態 |
| 適用ポリシーID | この通信を許可したファイアウォールポリシー番号 |
| タイムアウト値 | セッションが自動削除されるまでの残り時間 |
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: セッション情報の構成要素
proto=6はTCP、proto=17はUDPを意味します。proto_stateは内部状態コードで、01はESTABLISHED状態を示します。この数値は機種やバージョンで変わる場合があるため、状態確認には注意が必要です。
実運用環境では数千から数万のセッションが存在するため、全セッションを表示すると画面が流れてしまいます。diagnose sys sessionコマンドには強力なフィルタリングオプションがあり、目的のセッションだけを抽出できます。
diagnose sys session filter src 192.168.1.100
diagnose sys session listdiagnose sys session filter dport 443
diagnose sys session listdiagnose sys session filter policy 10
diagnose sys session listdiagnose sys session filter clear複数条件を組み合わせることも可能です。例えば、特定の送信元から特定の宛先ポートへの通信だけを表示したい場合は、フィルタを連続して設定します。
diagnose sys session filter src 192.168.1.100
diagnose sys session filter dport 443
diagnose sys session listFortiGateには機種ごとに最大セッション数の上限があり、この制限に達すると新規接続が拒否されます。セッション数を監視し、異常な増加を検知することは、安定運用の重要ポイントです。
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: セッション枯渇の主な原因
セッション枯渇時の対処法をまとめます。
| 対処法 | 実施内容 | 効果 |
|---|---|---|
| 異常セッション特定 | 送信元IP別にセッション数を集計 | 攻撃元の特定 |
| タイムアウト調整 | TCPタイムアウト値を短縮 | 古いセッション削除促進 |
| セッションクリア | 特定条件でセッション強制削除 | 即座にリソース解放 |
| ポリシー最適化 | 不要ポリシーの削除・統合 | 処理効率向上 |
「通信ができない」という障害報告を受けた際、セッションテーブルを確認することで、問題がFortiGate内部にあるのか、それとも外部要因かを切り分けられます。以下、実践的なトラブルシューティング手順を解説します。
送信元IPと宛先IP/ポートでフィルタし、セッションが作成されているか確認。セッションがなければポリシー設定を疑う。
proto_stateが01（ESTABLISHED）でなく、SYN_SENTのまま残っている場合、サーバー側に到達していない可能性が高い。
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を特定してクリアし、タイムアウト値の見直しも検討する
