FortiGateのトラブルシューティングで、GUIを眺めていても原因にたどり着けないことは多い。
本記事では、通信断・速度低下・ポリシー不一致といった現場の障害対応で
実際に手が伸びるCLIコマンドを、使う順番で整理する。

まず全体状態を確認する

get system performance status

CPU・メモリ・セッション数を一発で確認。CPUが張り付いている場合は
コンプロセッサ側かカーネル側かで切り分けの方向が変わる。

diagnose sys top 5

プロセス単位のCPU使用率。IPSエンジンやWADが暴れていないかを見る。

セッションの確認

「通信が通らない」ときに最初に見るのはセッションテーブル。

diagnose sys session filter dst 192.0.2.10
diagnose sys session filter dport 443
diagnose sys session list

フィルタを設定してからlistで絞り込み表示。見るべきポイントは以下。

  • state：may_dirtyやdirtyが付いていればルート/ポリシー変更の影響を受けたセッション
  • policy_id：意図したポリシーにヒットしているか
  • hook=post dir=org act=snat：NATの適用状況

フィルタは使い終わったら必ずクリアする。

diagnose sys session filter clear

パケットが来ているかを見る（sniffer）

「そもそもパケットがFortiGateに届いているのか」を確認する。

diagnose sniffer packet any 'host 192.0.2.10' 4 0 l
  • 第2引数：BPFフィルタ（tcpdump風に書ける）
  • 4：出力レベル（インターフェース名付きでヘッダ表示）
  • 0：無制限キャプチャ（Ctrl+Cで停止）
  • l：タイムスタンプを人間可読に

インターフェース名が表示されるレベル4が現場では一番使いやすい。
「wan1では見えるがlanで見えない」といった切り分けが一目でできる。

ポリシー判定の中身を追う（debug flow）

セッションもパケットも確認したうえで、FortiGateが
そのパケットをどう処理したかを追うのがdebug flow。

diagnose debug flow filter addr 192.0.2.10
diagnose debug flow trace start 100
diagnose debug enable

出力には「どのルートを引いたか」「どのポリシーにマッチしたか」
「なぜdropしたか」まで表示される。denied by forward policy check と出れば
ポリシー不一致、reverse path check fail と出ればRPF（非対称ルート）が原因。

確認が終わったら必ず無効化する。

diagnose debug disable
diagnose debug flow filter clear

過去の再起動・クラッシュの確認

「気づいたら再起動していた」ときはクラッシュログを見る。

diagnose debug crashlog read

まとめ

障害対応の順序は「状態確認 → セッション → sniffer → debug flow」。
上から順に実行すれば、レイヤを飛ばさずに原因へ到達できる。
debug系のコマンドは負荷がかかるため、本番機では
フィルタを必ず設定してから実行することを推奨する。