FortiGateのデバッグコマンド完全ガイド｜パケットキャプチャとフロー確認

FortiGateのトラブルシューティングにおいて、デバッグコマンドは切り札的存在です。通信が通らない、VPNが確立しない、ポリシーが効かない——こうした現場の課題を解決するには、パケットの実際の流れを可視化する必要があります。本記事では実務で頻繁に使う「diagnose debug flow」と「diagnose sniffer packet」の使い方を実例とともに解説します。

diagnose debug flowは、FortiGateを通過するパケットのフロー処理をリアルタイムで表示するコマンドです。ポリシーマッチング、NAT処理、ルーティング判定など、パケットが辿る全プロセスを可視化できます。

debug flowを使う際は、以下の4ステップで実行します。フィルタを適切に設定しないと大量のログが流れて解析困難になるため、必ず対象を絞り込みます。

diagnose debug flow filter addr 192.168.10.50
diagnose debug flow filter daddr 203.0.113.10
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
diagnose debug enable

このコマンド群により、送信元192.168.10.50から宛先203.0.113.10へのパケットを最大100フロー分追跡します。function-nameオプションで内部関数名も表示され、どの処理段階でドロップしたか特定できます。

debug flowで使用できる主要なフィルタを表1に示します。複数条件を組み合わせることで、ピンポイントでトラフィックを絞り込めます。

diagnose sniffer packetは、FortiGate上でtcpdumpライクなパケットキャプチャを実行するコマンドです。キャプチャしたデータをWiresharkで解析できるため、詳細なプロトコル分析が可能になります。

diagnose sniffer packet [インターフェース] '[フィルタ]' [詳細度] [パケット数] [タイムスタンプ]

# 実例：port1でHTTPSトラフィックを10パケットキャプチャ
diagnose sniffer packet port1 'host 192.168.10.50 and port 443' 4 10 a

詳細度パラメータは1〜6まであり、3以上を指定するとWireshark互換のpcap形式で出力されます。4が推奨で、ヘッダーとペイロード両方が記録されます。タイムスタンプは「a」で絶対時刻、「l」でUTC時刻になります。

pcap形式でキャプチャしたデータをWiresharkで解析する手順を説明します。SSHターミナルのログ保存機能を使うのが簡単です。

図1: デバッグコマンド使用頻度（実務調査）

IPsec VPNで通信できない場合、Phase1とPhase2のどちらで失敗しているか特定が最優先です。以下のコマンドで段階的に調査します。

# VPNトンネル状態確認
get vpn ipsec tunnel summary

# IKEネゴシエーション詳細デバッグ
diagnose debug application ike -1
diagnose debug enable

# パケットフロー追跡（暗号化前のトラフィック）
diagnose debug flow filter addr 172.16.10.5
diagnose debug flow trace start 50
diagnose debug enable

IKEデバッグ出力で「no suitable proposal」が表示された場合、暗号化アルゴリズムやDHグループのミスマッチです。Phase2でドロップされる場合は、セレクタ設定やルーティングを確認します。

通信が拒否される原因として、意図したポリシーにマッチしていないケースがあります。debug flowの出力で実際にマッチしたポリシーIDを確認できます。

# 出力例
id=20085 trace_id=123 func=print_pkt_detail line=5886 msg="vd-root:0 received a packet"
...
id=20085 trace_id=123 func=fw_forward_handler line=873 msg="Allowed by Policy-15"

この例では「Policy-15」にマッチしています。意図したポリシーと異なる場合、ポリシー順序やアドレスオブジェクト定義を見直します。「implicit deny」と表示された場合は、該当するポリシーが存在しません。

debug flowの出力は内部処理の順序で表示されます。表2に主要な処理ステージとその意味を示します。

パケットがドロップされる典型的な理由を理解しておくと、迅速な原因特定につながります。

図2: パケットドロップ理由の分布

# よくあるエラーメッセージ
- "reverse path check fail" → RPF失敗（非対称ルーティング）
- "policy deny" → ポリシーで明示的に拒否
- "no session matched" → 既存セッションが見つからない
- "SNAT failed" → NAT IPプールの枯渇

デバッグコマンドはCPUとメモリを大量に消費するため、調査完了後は必ず明示的に停止します。放置すると本番環境のパフォーマンス劣化やログの肥大化を招きます。

# debug flowの完全停止
diagnose debug disable
diagnose debug flow trace stop
diagnose debug flow filter clear
diagnose debug reset

# sniffer終了
Ctrl + C でキャプチャ停止

特に高トラフィック環境では、デバッグ実行中にCPU使用率が90%を超えることもあります。diagnose sys top コマンドでCPU負荷を監視しながら作業してください。また、フィルタを緩くしすぎると膨大なログが出力されるため、必ず送信元・宛先IPで絞り込むことを推奨します。