「アプリケーション層に送信」メッセージを分析します。
デバッグ出力で最も重要な行は次のとおりです: id=65308 ... func=av_receive ... msg="send to application layer" 意味: このメッセージは、FortiGate カーネルがパケットをユーザー空間デーモン (具体的には、av_receive ハンドラーで示される WAD/Proxy プロセス) に渡して詳細な検査を行っていることを示します。
意味：この動作はプロキシベースの検査の特徴です。フローベースの検査では、トラフィックはIPSエンジン（多くの場合カーネル内、またはips_measureなどの特定のIPSハンドラー経由）によって処理されるため、標準的なWebフィルタリングでは「アプリケーション層に送信」というメッセージが表示されることは通常ありません。
オプション B (ファイアウォール ポリシー モード) を評価します。
トラフィックはアプリケーション層プロキシに送信されるため、このトラフィックを制御するファイアウォールポリシー（「Allowed by Policy-1」に示されているポリシーID 1）は、インスペクションモードを「プロキシ」に設定する必要があります。フローベースであれば、トラフィックはフローパス内に留まります。したがって、オプションBが正解です。
オプション C (Web フィルター プロファイル モード) を評価します。
FortiOSでは、ファイアウォールポリシーがプロキシベースのインスペクションに設定されている場合、そのポリシーに適用されているセキュリティプロファイル（Webフィルタなど）もプロキシベースのインスペクションモードで動作します。av_receive関数の存在は、コンテンツインスペクション（Webフィルタ/AV）がプロキシエンジンによって実行されていることを示しています。したがって、オプションCが正解です。
オプション A が間違っている理由 (NPU オフロード):
出力にはnpu_state=0x100と表示されています。トラフィックが「アプリケーション層に送信」されているフロートレースのコンテキストでは、これはセッションがNPU（ネットワークプロセッサ）に完全にオフロードされていないことを示しています。オフロードされたトラフィック（Fast Path）はハードウェアによって処理されるため、ペイロード検査フェーズに関するこれらのCPUレベルのデバッグログは生成されません。プロキシ処理にはCPUの介入が必要です。
オプション D が間違っている理由 (ポート マッピング):
検査には有効なプロトコルマッピングが必要ですが、表示されている特定のデバッグ出力は、検査モード（プロキシ vs. フロー）の直接的な結果です。アプリケーション層に移動するトラフィックの観察は、主にポリシーとプロファイルモードの設定によって行われるため、BとCはログデータから得られた直接的な「観察結果」となります。
参照：
FortiGate トラブルシューティング (デバッグ フロー):「デバッグ フローに msg='send to application layer' と表示されている場合、トラフィックがプロキシベースの検査のためにプロキシ (WAD) によって処理されていることが確認されます。」

ipsengine に関連するこの CPU 使用率の高いシナリオを解決するには、トラブルシューティング手順に示されている診断テスト アプリケーションの ipsmonitor コマンドの特定の機能を理解する必要があります。
* 状況を分析する:
* 図: diagnose sys top の出力には、ipsengine プロセスが実行状態 (R) にあり、CPU の 99% を消費していることがわかります。
* 以前のアクション: 管理者は診断テスト アプリケーション ipsmonitor 5 を既に実行しています。
* 結果: CPU 使用率は低下しませんでした。
* コマンドを理解する:
* diagnose test application ipsmonitor 5: このコマンドはIPSバイパスモードを切り替えます。有効にすると、IPSエンジンはトラフィックを検査なしで通過させます。
* 意味: トラフィック量により CPU 使用率が高くなった場合、バイパスを有効にすると CPU 負荷がすぐに低下します。
* 失敗: バイパス後もCPU使用率が99%のままであるため、ipsengineプロセスはフリーズ、スタック、または現在のトラフィックフローとは無関係な内部無限ループに陥っている可能性があります。問題はトラフィック量ではなく、プロセス自体です。
* ソリューションを評価する（オプション B）:
* diagnose test application ipsmonitor 2: このコマンドはIPSエンジンの有効/無効を切り替えます。
/無効ステータス。
* エンジンが動かなくなっている (バイパスが圧力を解放できなかった) ため、必要な「即時アクション」はプロセスを完全に停止するか、再起動することです。
* オプション 2 を実行すると、スタックした IPS エンジン インスタンスが効果的に無効化/強制終了され、CPU 使用率が即座にほぼゼロまで低下します (その後、再度切り替えて再起動できます)。
* 他の選択肢が間違っている理由:
* A (署名の削減): これは通常の操作のためのチューニング手段であり、CPU 使用率が 99% で停止したプロセスをすぐに修正するものではありません。
* C (ポリシーで IPS を無効にする): これは時間がかかり、コミットが必要な構成変更であり、最も即時に使用できる診断ツールではありません。
* D (すべての IPS エンジンをバイパス): これはコマンド 5 (バイパス) のアクションを表します。プロンプトには、このアクションがすでに実行され、失敗したことが明示的に示されます。
参照：
FortiGate Security 7.6 学習ガイド (IPS および診断)：「IPS 高 CPU のトラブルシューティング: 1. 上部を確認します。2.
バイパスを試してください (ipsmonitor 5)。3. CPU が引き続き発生する場合は、エンジンを再起動してください (ipsmonitor 99 または 2)。

質問 4 の図には、ポリシー ルート テーブル エントリが示されており、主要なフィールドは次のとおりです。
* インターネットサービス(1): Fortinet-FortiGuard(1245324,0.0.0.0,0.0.0.0)
Fortinetの公式ドキュメントによると、ポリシールートがインターネットサービスデータベース（ISDB）エントリに基づいている場合、ルートエントリには「インターネットサービス」が明示的に記載され、参照されているサービス（この例ではFortinet-FortiGuard）が示されます。これは、ISDBシグネチャを参照せずに、送信元、宛先、およびサービスのワイルドカードで定義される通常のポリシールートとは根本的に異なります。通常のポリシールートの出力には「インターネットサービス」という行は含まれません。ISDBを使用するポリシールートでは、宛先IPが動的であっても、FortiGateはトラフィックパターン認識に基づいて、特定の既知のサービス（FortiGuard、Google、Microsoftなど）へのトラフィックを誘導できます。マッチングとルート選択はISDBタグに従って行われ、静的または通常のポリシールートと共存できます。
したがって、このエントリは、FortiOS ポリシー ルーティング ドキュメントおよび ISDB 構成リファレンスで説明されているように、正しく一意に ISDB ルートです。
参考文献:
FortiOS 管理ガイド: ポリシールーティング、ISDB 統合、ルートテーブルエントリの解釈、ISDB ベースのルーティング、および Fortinet ドキュメントの公式 CLI 出力

失敗の原因を特定するには、展示物 (image_ad3dc6.jpg) で提供されている IKEv2 デバッグ出力を分析する必要があります。
交渉段階を特定する:
デバッグ ログには、応答側が CREATE_CHILD 交換を受信したことが表示されます。
IKEv2 では、CREATE_CHILD_SA 交換は、新しい子 SA (フェーズ 2) を作成するか、既存の子 SA のキーを再生成するために使用されます。
トンネルが以前に「正常に起動した」という事実は、初期の IKE SA (フェーズ 1) が安定していることを意味し、このエラーは特に Perfect Forward Secrecy (PFS) が関係することが多いキー再生成イベント中に発生しています。
提案を分析する（不一致）:
着信提案（リモートピア）:
リモート ピアは、type=DH_GROUP、val=MODP2048 (グループ 14) と type=DH_GROUP、val=MODP1536 (グループ 5) の 2 つの Diffie-Hellman グループを含む提案を送信します。
私の提案（ローカルFortiGate）:
ローカル FortiGate 構成では、type=DH_GROUP、val=MODP3072 (グループ 15) が想定されています。
交渉の結果:
デバッグ出力は、「提案が選択されませんでした」および「ネゴシエート SA エラー」で終わります。
このエラーは、ローカル FortiGate が、要求するもの (グループ 15) とピアが提供しているもの (グループ 14 または 5) の間に共通の Diffie-Hellman グループを見つけられないために発生します。
これは技術的にはフェーズ 2 (子 SA) の作成中に発生する不一致ですが、「Diffie-Hellman 不一致」(オプション A) がログで特定された正確な根本原因です。
他のオプションが間違っている理由:
B: ログには受信した create-child 要求が表示され、UDP トラフィックがデバイスに到達しており、ブロックされていないことが確認されます。
C: 失敗は IKE_SA_INIT または IKE_AUTH (フェーズ 1) 交換ではなく、CREATE_CHILD 交換 (フェーズ 2/キー更新) で発生します。
D: フェーズ 2 の定義内で不一致が発生していますが、DH_GROUP 行に表示される「提案が選択されなかった」エラーの具体的な技術的理由はオプション A です。
参照：
FortiGate Security 7.6 学習ガイド (IPsec VPN):「フェーズ 2 パラメータ... Perfect Forward Secrecy (PFS) が有効になっている場合、Diffie-Hellman 交換が再度実行されます。両方のピアの DH グループが一致している必要があります。」