ビジネスサポートポータルアカウントでログイン
 

DSVA環境のトラブルシューティングガイド

    • 更新日:
    • 22 Sep 2021
    • 製品/バージョン:
    • Trend Micro Deep Security 10.0
    • Trend Micro Deep Security 11.0
    • Trend Micro Deep Security 12.0
    • Trend Micro Deep Security 20.0
    • Trend Micro Deep Security 9.6
    • OS:
    • Virtual Appliance
概要

NSX環境におけるトラブルシューティングのナレッジを教えてください。

詳細
Public
本ページではNSX環境における基礎及びトラブルシューティングのナレッジを以下の通りシチュエーション別におまとめしております。
Deep Security ヘルプセンターへのリンクは原則としてDeep Security 20.0のドキュメントとなっております。 20.0以外のバージョンの記事を参照いただく場合、ヘルプセンター上のバージョンを変更ください。なお、リダイレクトにより各バージョンのトップページに移行した場合は検索ボックスにて関連ワードを検索ください。
詳細すべて確認

DSVA環境にて問題が発生した際のトラブルシューティング方法

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

製品Q&A:DSVA環境のトラブルシューティングステップを参照ください。

※「不正プログラム対策エンジンのオフライン」などよくあるお問合せは本ページの下部におまとめしております。併せてご確認ください。

DSVA環境の基礎知識

DSVA環境の通信フロー図

DSVA環境における状況別の通信フローを解説します。 詳細な通信要件は こちらを参照ください。

通信フロー:概要

  • 通信1:DSMとNSX-V/T Manager, vCenter間の通信

    仮想マシンの管理情報やNSXセキュリティグループの設定を取得します。

  • 通信2:DSMとDSVA間の通信

    ハートビートや各種イベントの送付、タスクの実行命令、仮想マシンの管理情報などのやり取りを行います。

    DSVA管理下の各仮想マシンは直接DSMとの通信を行いません。各仮想マシンに対応したVirtual Agent(仮想マシンの管理情報)が管理下のDSVA上に作成され、DSVAがDSMと通信を行います。

    例外としてコンバインモードの実施時があります(コンバインモードに関してはこちらを参照ください)。コンバインモード実施時は仮想マシンの管理情報はDSVA側で管理されるVirtual Agentと仮想マシン内で実行されるAgentの2つがございます。 Virtual Agentは引き続きDSVAにより管理され、DSVAがDSMと通信を行います。AgentはAgent自身がDSMと通信を行います。DSMからAgentへの通信の際はDSMはvCenterから引き渡された仮想マシンのIPアドレス(1つ)を元にAgentと通信を行います。そのため、インタフェースが複数存在する場合は期待外のIPアドレスが引き渡される可能性があります。 その場合は引き渡されたIPアドレスの使用ではなく、DSMから仮想マシンへの名前解決を行うよう設定変更を行うことで回避が可能となります。詳細は製品Q&A: DSMからDSVAや仮想マシンへの通信時、名前解決をしていない を参照ください。

  • 通信3:DSMとRelay間の通信

    ハートビートやセキュリティアップデートなどを行います。

  • 通信4:DSVAからRelayへの通信

    セキュリティアップデート、アップデート用のソフトウェアの取得などを行います。

  • 通信5:DSVAからSmart Protection Networkへの通信

    Smart Protection Network へのクエリを行います。

    5274ポートへの通信はLocal Smart Protection Networkが対象

  • 通信6:Relayからダウンロードセンターへの通信

    ダウンロードセンターから最新のセキュリティアップデート、ソフトウェアアップデートの取得します。


通信フロー:DSVAの展開時

  • 通信1:DSMとNSX-V/T Manager, vCenter間の通信

    DSVAのovfファイルやNSXセキュリティグループ、仮想マシンの管理情報の取得などを取得します。その後、ESXiにOVF情報、DSVAの情報(IPアドレスやNWラベルなど)が連携されESXi上でDSVAが展開されます。2台目以降は1台目のDSVAのスナップショットが各ESXi上に展開されます。

  • 通信2: DSMとDSVA間の通信

    DSVAの展開後、DSVAが有効化されます。

  • 通信3:DSVAとDSRの通信

    DSVAの有効化後、[DSM管理コンソール]>[システム設定]>[アップデート]タブ>[Virtual Applianceの配置]に設定されたバージョンにDSVAが自動的にアップグレードされます(初期設定ではDSM内の最新のビルドにアップグレードされます。詳細はこちらを参照ください)。その後、セキュリティアップデートが実施されます。


通信フロー:仮想マシンのvMotion時

  • 通信1:DSMとNSX-V/T Manager, vCenter server間の通信

    仮想マシンの移動情報(どのESXiで管理されるかなど)の取得を行います。

  • 通信2:DSMおよびDSVA間の通信

    仮想マシンの移動情報を受け、仮想マシンの移動元DSVA上で仮想マシンの管理情報(Virtual Agent)の削除し、一部管理情報をRelayに送信します。移動先DSVA上にて仮想マシンの管理情報(Virtual Agent)を作成、Relayから一部管理情報を取得します。


通信フロー:不正プログラム対策機能の動作時(NSX-V編)

補足

  • 通信2と通信3のセッションは仮想マシンごとに作成されます。

  • 不正プログラム対策エンジンのオフライン」が発生する場合、不正プログラム対策機能をオンにした際に通信3にてMUXからDSVA(初期設定では48651ポート)に対して、セッションが張れていない可能性がございます。対処としてセッションの確認方法も含め、よくあるお問合せ内の「不正プログラム対策エンジンがオフラインの解消方法」の項を参照ください。

  • 通信1:仮想マシンとvShield-Endpoint-MUX(以下、MUX)プロセスへの通信

    仮想マシンのVMware Tools内のVMCIからESXi上のMUXプロセスへの通信。通信3まで完了後に不正プログラムのスキャンが行える状態となる。

  • 通信2:MUXからGuest Introspectionへの通信

    MUXからGuest Introspectionの169.254.1.24:48655ポートにセッション構築される。

  • 通信3:MUXからDSVAへの通信

    MUXとGuest Introspectionのセッションが構築後、MUXからDSVAの48651ポートにセッションが構築される。セッション構築完了後、仮想マシンからのスキャン情報の処理が可能となる。

  • 通信4:DSMとDSVAの通信

    構築された通信3のセッション情報 (不正プログラム対策機能のドライバがオンライン)がハートビートにてDSMに送られ、該当仮想マシンの不正プログラム対策機能のステータスがオンとなる。


通信フロー:不正プログラム対策機能の動作時(NSX-T編)

補足

  • 通信2のセッションは仮想マシンごとに作成されます。

  • 「不正プログラム対策エンジンのオフライン」が発生する場合、不正プログラム対策機能をオンにした際に上記[通信2]にてMUXプロセスからDSVA(初期設定では48651ポート)に対して、セッションが張れていない可能性がございます。対処としてセッションの確認方法も含め、よくあるお問合せ内の「不正プログラム対策エンジンがオフラインの解消方法」の項を参照ください。

  • 通信1:仮想マシンとContext Multiplexer (以下、MUX)プロセスへの通信

    仮想マシンのVMware Tools内のVMCIからESXi上のMUXプロセスへの通信。通信2まで完了後に不正プログラムのスキャンが行える状態となります。

  • 通信2: MUXからDSVAへの通信

    MUXからDSVAの48651ポートにセッションが構築されます。セッションの構築完了後、仮想マシンからのスキャン情報の処理が可能となります。


通信フロー:Webレピュテーション、ファイアウォール、侵入防御機能の動作時(NSX-V環境)

  • 通信1:仮想マシンへのパケットの受信

    仮想マシン宛の通信パケットをESXiが受信

  • 通信2:dvfilterからDSVAへの通信のリダイレクト

    ESXi上のdvfilterドライバからDSVAのdsa_slowpath_nx プロセスへパケットが転送されDSVAにて処理されます。

  • 通信3:dvfilterから仮想マシンへの通信のリダイレクト

    DSVAでのパケット処理後にパケットのドロップに該当しない場合、ESXi上のdvfilterドライバから仮想マシンへパケットが転送されます。

  • 通信4:DSMとDSVAの通信

    ハートビートや各種イベントの送付など


通信フロー:Webレピュテーション、ファイアウォール、侵入防御機能の動作時(NSX-T環境)

  • 通信1:仮想マシンへのパケットの受信

    仮想マシン宛の通信パケットをESXiが受信

  • 通信2:dvfilterからDSVAへの通信のリダイレクト

    ESXi上のdvfilterドライバからDSVAのdsa_slowpath_nsxt プロセスへパケットが転送されDSVAにて処理されます。この時、仮想マシンとDSVAが同じトランスポートゾーンオーバレイに属している必要があります(詳細はこちら)。

  • 通信3:dvfilterから仮想マシンへの通信のリダイレクト

    DSVAでのパケット処理後にパケットのドロップに該当しない場合、ESXi上のdvfilterドライバから仮想マシンへパケットが転送されます。

  • 通信4:DSMとDSVAの通信

    ハートビートや各種イベントの送付など

DSVA環境の導入方法

DSVA環境の導入に際し以下ドキュメントがございます。

NSX-V環境の場合Applianceのインストール (NSX-V)を参照ください。

NSX-T 3.0未満の環境の場合はApplianceのインストール (NSX-T)
NSX-T 3.0以上の環境の場合はアプライアンスを配信する(NSX-T 3.x)、を参照ください。

DSVAの配信前にリソースの設定の変更を行う場合は Deep Security Virtual Applianceのメモリ割り当てを参照ください。

※環境からの削除はNSX環境からのDeep Securityのアンインストールを参照ください。

Deep Security/VMwareコンポーネントのバージョン確認手順

Deep Security/VMwareコンポーネントのバージョン確認手順

お問合せ時にはご利用いただいております環境上のDeep Security/VMware製品のバージョンをご確認させていただきます。本ドキュメントを参考に各コンポーネントのバージョンをご確認ください。 なお、バージョン間の互換に関しましてはこちらを参照ください。

バージョン確認一覧


DSMのバージョン確認

[DSM管理コンソール]>画面右上の[サポート情報]>[バージョン情報]


Relay/DSAのバージョン確認

[DSM管理コンソール]>[コンピュータ]>対象のコンピュータの[詳細]>[概要]>[処理]タブ>Agentソフトウェア内のバージョン


DSVAのバージョン確認

[DSM管理コンソール]>[コンピュータ]>対象のコンピュータの[詳細]>[概要]>[一般]タブ>Virtual Applianceのバージョン、Appliance(SVM)のバージョン

Virtual Applianceのバージョンは現在のDSVAのバージョン、Appliance (SVM) のバージョンは使用したOVFファイルのバージョンを示します。

vCenter ServerとESXiのバージョン確認

[vCenter Serverの管理コンソール]>[グローバルインベントリリスト]>[リソース]>[vCenter Server]>[サマリ]

[vCenter Serverの管理コンソール]>[グローバルインベントリリスト]>[リソース]>[ホスト]>[サマリ]


NSX-V Managerのバージョン確認

  • NSX-V Managerのバージョン

    [vCenter Serverの管理コンソール]>[Networking and Security]>[NSX ホーム]>[サマリ]

    Deep Security環境でNSXを使用する際は、使用するライセンスにより一部機能に制限が生じるため、ライセンスのエディションは重要な情報となります。 詳細はこちらを参照ください。

  • Guest Introspectionのバージョン

    [vCenter Serverの管理コンソール]>[Networking and Security]>[インストールとアップグレード]>[サービスの展開]

    Guest Introspectionは不正プログラム対策および変更監視の機能利用時に使用されます。

  • Network Introspectionのバージョン

    [vCenter Serverの管理コンソール]>[Networking and Security]>[インストールとアップグレード]

    Network IntrospectionはWebレピュテーション、ファイアウォール、侵入防御の機能利用時に使用されます。

NSX-T Managerのバージョン確認

[NSX-T managerの管理コンソール]>[システム]>[アプライアンス]

vCenter tools/Guest Introspectionドライバーのバージョン確認

  • vCenter toolsのバージョン

    確認対象の仮想マシンにログイン>デスクトップ上のVMアイコンを右クリック>[VMware Toolsについて]


  • Guest Introspectionドライバーのバージョン

    [ファイル名を指定して実行]から[C:\Windows\System32\drivers]>[vsepfilt.sys]を右クリック>プロパティ

    留意事項

    VMware Tools にはNSX File Introspection Driver/NSXファイル自己検証ドライバ(旧:Guest Introspectionドライバー)が同梱されていますが、標準インストールではインストールされないため、Vmware Toolsのインストール時にカスタムorコンプリートインストールでNSX File Introspection Driverをインストールする必要があります。

    VMware Toolsカスタムインストール時の選択画面
    DSVAの動作におきまして、NSX Network Introspection Driver/NSX ネットワーク自己検証ドライバのインストールは不要です(詳細はこちら)。


DSVAの再配信方法

DSVAの再配信方法は Deep Security Virtual Appliance(DSVA)を削除/再配信する方法を参照ください。

DSVAへのログイン・SSHの有効化方法

コンソールへのログイン方法

vCenter(もしくはESXi)の管理コンソール上からDSVAのコンソールにアクセスしトップ画面上で、[Alt]+[F2]を入力することにより、GUIからコマンドラインインタフェース画面に移動可能です([Alt]+[F1]でGUIに戻ります)。

ユーザ名:dsva

パスワード:dsva

SSHの有効化方法

  1. デフォルトのDeep Security Virtual Applianceポリシーなど、ssh接続が禁止されているポリシーを使用している場合、ポリシーメニューからポリシー編集画面を開き、[割り当て/割り当て解除]ボタンから、sshで該当サービスを検索し、Remote Access SSHサービスを受信接続許可します。
  2. DSVAのコンソールにログイン後、sudo service sshd start コマンドを実行し、sshdサービスを実行します。
  3. (オプション)DSVA再起動時もsshdを常に有効にする場合は、sudo chkconfig sshd on コマンドも実行しておきます。
    • DSVAを再配信などで削除された場合は初期設定にて配信されますため再度実施いただく必要がございます。

    • DSVAは標準で英語キーボード設定のため、日本語キーボードで”|”を入力するためには、+”]” キーを使用します。

    各コンポーネントの再起動方法

    動作不調時などの各コンポーネントの再起動手順は以下となります。

    Guest Introspection VM, vShield-Endpoint-Mux, nsx-context-muxに関しましてはVMware製品のコンポーネントとなります。再起動やコマンド実行に関する影響は事前にVMware社様へご確認ください。

    DSVA

    Guest Introspection VMが起動している状態でDSVAを起動ください。

    1. vCenter管理コンソールにログイン
    2. [ホスト及びクラスタ]>対象のDSVAを右クリックし[電源]>[ゲストOSの再起動]

    Guest Introspection VM(NSX-V環境)


    1. vCenter管理コンソールにログイン
    2. [ホスト及びクラスタ]>対象のGuest Introspection VMを右クリックし[電源]>[ゲストOSの再起動]

    vShield-Endpoint-Mux(NSX-V環境)

    1. ESXiにログインします。

    2. 以下のコマンドを実施します。

      /etc/init.d/vShield-Endpoint-Mux restart

      起動後、以下のコマンドにてサービスがrunningとなっていることを確認ください。

      /etc/init.d/vShield-Endpoint-Mux status


    nsx-context-mux(NSX-T環境)


    1. ESXiにログインします。

    2. 以下のコマンドを実施します。

      /etc/init.d/nsx-context-mux restart

      起動後、以下のコマンドにてサービスがrunningとなっていることを確認ください。

      /etc/init.d/nsx-context-mux status

    不正プログラム対策機能の処理パフォーマンス、除外設定

    よくあるお問合せ

    不正プログラム対策エンジンがオフラインの解消方法

    DSVAはVMware側の複数のコンポーネントと密接に連携することにより動作しております。そのため、Deep Security側コンポーネントのみでエラーが発生している場合でもVMware側コンポーネントの設定や動作不良によって発生する可能性もございます。 そのため、「どのESXi上」で「何台中何台の仮想マシン」に「どのようなタイミング」で「何のアラート」が発生しているかを整理si障害点を洗い出すことがトラブルシュートのポイントとなります。

    【Step1】問題発生対象の確認

    「不正プログラム対策エンジンがオフライン」アラートがどのESXi上で何台の仮想マシンで発生しているか、 製品Q&A:DSVA環境のトラブルシューティングステップ>「【Step1】問題発生対象」の確認をもとにパターンを分類し発生対象ESXiと仮想マシンを整理します。


    【Step2】トラブルシューティング

    整理した発生状況からトラブルシューティングを実施します。本項記載の「不正プログラム対策エンジンがオフライン」アラートの発生要因としましては主にMUXからDSVAの169.254.1.39:48651にセッションが張れていない状態が考えられます

    • NSX-V環境の場合は以下図の通信3が該当します。(DSVA環境の通信フロー図の不正プログラム対策機能の動作時(NSX-V編)より抜粋)


    • NSX-T環境の場合は以下図の通信2が該当します。(DSVA環境の通信フロー図の不正プログラム対策機能の動作時(NSX-T編)より抜粋)


    ※通信の詳細な解説は[DSVA環境の通信フロー]の項を参照ください

    そのため、まずはDSVAの169.254.1.39:48651にMUXからセッションが構築されているかを確認します。

    確認方法

    1. DSVAにログイン(ログイン方法は[DSVAへのログイン・SSHの有効化方法]を参照ください)

    2. 以下のコマンドにてセッションの接続可否を確認します。

      netstat -ant

      netstat -ant | grep 169.254.1.39:48651 | wc

      確認ポイントとしては以下の2点です。

      1. 0.0.0.0:48651ポートがLISTEN状態であること
      2. 169.254.1.39:48651へのTCPコネクションがESTABLISTHEDであること

      169.254.1.39:48651への接続は現在保護対象となっている仮想マシンのノード数分確立されます。上記図の例ではDSM管理コンソール上で3台の仮想マシンがDSVAの保護下となっており、3台ともDSVAにセッションが張られている正常な状態となります。

      補足

      • セッションの送信元となるMUX側のアドレスはNSX-V環境の場合は169.254.1.1、NSX-T環境の場合は169.254.1.2となります。

    セッションの確立がされていない場合、その要因としては以下が考えられます。

    • 要因1:セキュリティグループの設定

      確認ポイント

      • 対象仮想マシンにセキュリティグループ(NSX-V環境) or エンドポイント保護(NSX-T環境)の設定がされていない

      対処法

      • 設定されているセキュリティグループ(NSX-V環境) or エンドポイント保護(NSX-T環境)に対象の仮想マシンが含まれているかご確認ください。

        確認方法

        NSX-V環境の場合はApplianceのインストール (NSX-V)の[手順6:NSXセキュリティグループとポリシーを作成する]を参照ください。

        NSX-T 3.0未満の環境の場合Applianceのインストール (NSX-T)の[手順5: エンドポイント保護を設定する]を

        NSX-T 3.0以上の環境の場合アプライアンスを配信する(NSX-T 3.x)Endpoint Protectionの設定を参照ください。

      • 設定に問題がない場合、設定項目がDSMに同期されていない可能性があります。
        製品Q&A:DSVA環境のトラブルシューティングステップ>Step2>「vCenter/NSX Manager同期確認」 を参照しDSMとvCenter/NSX Managerとの同期を実施ください。


    • 要因2:仮想マシン/VMware Toolsが起動していない

      確認ポイント

      • 仮想マシンがスリープになっていないか
      • 仮想マシンにVMware Tools及びGuest Introspectionドライバ(vsepflt)がインストールされているか
      • 仮想マシン上でVMware Toolsが起動しているか
      • Guest Introspection関連ドライバ(vsepflt/vmci)が停止していないか

      対処法

      • 仮想マシンにログインを行い、下記製品Q&Aをご参照の上、VMware Tools関連モジュールの正常性確認を実施ください。

        製品Q&A:DSVA環境のトラブルシューティングステップ >Step2>「保護対象仮想マシンのステータス確認(仮想マシンにログインの上確認)」>「Guest Introspectionドライバー状態(不正プログラム対策/変更監視機能利用時)」

      • 上記に問題がない場合、モジュールの読み込みのため対象仮想マシンのOS再起動を実施ください。

      • VMware toolsを最新版へアップデートください。

        VMware Toolsに関しましてはVMware製品側の互換性を満たしているかご確認ください(製品Q&A:Deep Security and VMware compatibility matrix(英語のみ)のVMware toolsの項を参照ください)。


    • 要因3:MUXからDSVAへの通信有無

      確認ポイント

      • DSVAが正常動作しているか
      • Guest Introspection VMが存在/正常動作しているか(NSX-V環境のみ)
      • MUXプロセスが正常動作しているか

      対処法

      • 対象仮想マシンをvMotionなどで別のESXi上、別のDSVAの管理下に移動させセッションが構築されるか確認します。

        1. 対象仮想マシンの移動にてセッションが構築される場合は移動元のDSVA,Guest Introspection VM, MUXプロセスのいずれかが正常に動作していない可能性があります。

          製品Q&A:DSVA環境のトラブルシューティングステップ >Step2 にて各コンポーネントの正常性を確認ください。確認結果にて障害点が確認された場合、関連コンポーネントの再起動(各再起動の手順は本製品Q&A内の[各コンポーネントの再起動方法]を参照ください)、もしくはDSVA および Guest Introspection VMの再配信(再配信手順は本製品Q&A内の[DSVAの再配信方法]を参照ください)を実施することで事象の改善が見込まれます。

        2. 対象仮想マシンの移動にてセッションが構築されない場合はその他の要因が問題の可能性があります。


    要因1から3の対処法にて改善が見られない場合、その他の要因としては以下が考えられます。

    • 要因4:環境負荷

      ポイント

      • 環境負荷が高くDSVAの動作が安定しない

      対処法

      • DSVAの再起動([各コンポーネントの再起動方法]の項を参照ください)
      • DSVAの再配信([DSVAの再配信方法]の項を参照ください)

      DSVAの再起動、再配信によるリフレッシュにて改善し、事象が再発する場合は環境負荷が高い可能性がありますので改めて サイジングをご確認ください。なお、サイジング表上リソースが満たされている環境であっても使用状況によりましてはリソースが不足している可能性がございます。 そのため、再起動後に再発がされる場合は一時的にでもDSVAに設定されているCPUおよびメモリリソースを段階的に上げる(目安としてCPUの場合は6~8core程度、メモリの場合は12~16GB程度)ことで事象が改善するかをご確認ください。


    • 要因5:NSXコンポーネントの不具合

      NSX-Vでは「不正プログラム対策エンジンのオフライン」エラーが発生する不具合が多数報告されております。いずれもNSX-V Manager 6.4.4以上にて修正がされているものとなりますため、6.4.4以上でのご利用をご検討ください。


    その他、仮想マシンのパワーオン時やvMotionを行った際に一時的に本エラーが発生する場合がございます。10分程度(ハートビートの間隔となります)で解消がする場合はセッション確立までの一時的なエラーと考えられますので無視いただいて問題ございません (詳細は製品Q&A:Creation of multiple virtual machines using Horizon VDI causes Anti-Malware engine offline(英語のみ)を参照ください)。

    Notiferの到達不能エラー解消方法

    DSVA環境ではエージェントレスでの保護を実現するため、Deep Security側コンポーネントは仮想マシンと直接通信を行わず、VMware側コンポーネントを介して通信します。

    DSVAは不正プログラム対策機能のリアルタイム検索機能を利用し仮想マシン側に通知・管理情報を伝えることで仮想マシン側でNotifierに情報を表示します。 そのため、Notifierが動作するには以下を満たす必要があります。

    条件

    • 不正プログラム対策機能のリアルタイム機能がオン
      →手動検索や予約検索のみの設定では使用不可

    • 「不正プログラム対策エンジンのオフライン」ステータスが発生していない

    • ドライバレベル(ディレクトリ)の検索除外でNotifier用のファイルを除外していない
      →詳細は製品Q&A:Deep Security Notifier のステータスが「不明/到達不能」になっているを参照ください

    コンバインモードをご利用の場合、DSVAにて保護している機能は上記機能でDSVAが不正プログラム対策機能のリアルタイム検索機能を利用しNotifierに伝えます。Agentにて保護している機能はAgent自身がNotifierに伝えます。

    ファイアウォールエンジン、侵入防御エンジンがオフラインの解消方法

    DSVAはVMware側の複数のコンポーネントと密接に連携することにより動作しております。そのため、Deep Security側コンポーネントのみでエラーが発生している場合でもVMware側コンポーネントの設定や動作不良によって発生する可能性もございます。 そのため、「どのESXi上」で「何台中何台の仮想マシン」に「どのようなタイミング」で「何のアラート」が発生しているかを整理し障害点を洗い出すことがトラブルシュートのポイントとなります。

    【Step1】問題発生対象の確認

    まずは「ファイアウォール/侵入防御エンジンがオフライン」アラートがどのESXi上で何台の仮想マシンで発生しているか、 製品Q&A:DSVA環境のトラブルシューティングステップ>「【Step1】問題発生対象」の確認をもとにパターンを分類し発生対象ESXiと仮想マシンを整理します。

    【Step2】トラブルシューティング

    整理した発生状況からトラブルシューティングを実施します。 本項記載の「ファイアウォール/侵入防御エンジンがオフライン」アラートの発生要因としましては主にDSVAがESXi上のdvfilterと通信が行えない場合に発生します。通信フロー上は以下図の通信2-3が該当します。


    • Webレピュテーション、ファイアウォール、侵入防御機能の動作時(NSX-V環境)

    • Webレピュテーション、ファイアウォール、侵入防御機能の動作時(NSX-T環境)

    ※通信の詳細な解説は[DSVA環境の通信フロー]の項を参照ください

    Webレピュテーション、ファイアウォール、侵入防御機能いずれかの機能をDSVAにてご利用の場合は下記を参照いただきトラブルシューティングを実施ください。

    • 要因1:Network Introspection設定ミス

      • 対処法(NSX-V環境の場合)

        [vCenter管理コンソール]>[ホーム]>[ネットワークとセキュリティ]>[Service Composer]>[セキュリティグループ]メニューでセキュリティポリシーのネットワークイントロスペクションサービスが設定されていること、セキュリティグループに該当の仮想マシンが所属していることを確認してください。


      • 対処法(NSX-T環境の場合)

        NSX-T環境でのネットワーク機能の利用の場合、Network Introspection設定が誤っている場合でもDeep Security上の管理コンソールでは特段エンジンオフラインといったエラーは発生しないものとなります。DSVA自体はパケットのリダイレクトを常時待っている状態となるためです。 そのため、本機能を利用時は必ず以下のリダイレクト設定をご確認ください。 Network Introspection設定確認ポイントは以下を参照ください。なお、詳細な解説はこちら を参照ください。

        1. [NSX-T管理コンソール]>[セキュリティ]>[設定]>[ネットワークイントロスペクション]メニューでサービスセグメント、サービスプロファイル、サービスチェーンの設定がされていること



        2. [NSX-T管理コンソール]>[セキュリティ]>[East-Westのセキュリティ]>[ネットワーク イントロスペクション (E-W)]にてリダイレクトポリシーおよび仮想マシンに対するルールが設定されていること

        補足

        NSX for vShield Endpoint ライセンスご利用時などでNSX側機能に制限がある場合でもDeep Security側のライセンスに問題がなければWebレピュテーション、ファイアウォール、侵入防御機能の機能を自体をオンにすることは可能となります (NSX側のライセンスに対するDeep Security側で使用可能となる機能に関しましてはこちらを参照ください)。 しかしながら、DSVAへのパケットのリダイレクトがされない状態となりますため、該当機能での処理は行われないものとなります。また、Deep Secutrity側にて特段エラーなどは発生しないものとなりますことをご留意ください。

    • 要因2:DSVA or ESXi側プロセスの障害

      対処法

      DSVAの再起動、再配信によるリフレッシュにて改善し、事象が再発する場合は環境負荷が高い可能性がありますので改めて サイジングをご確認ください。なお、サイジング表上リソースが満たされている環境であっても使用状況によりましてはリソースが不足している可能性がございます。 そのため、再起動後に再発がされる場合は一時的にでもDSVAに設定されているCPUおよびメモリリソースを段階的に上げる(目安としてCPUの場合は6~8core程度、メモリの場合は12~16GB程度)ことで事象が改善するかをご確認ください。

      1. ESXiにログイン

      2. 製品Q&A:DSVA環境のトラブルシューティングステップ>[Step 2環境の正常性確認]にて以下を確認ください。

        • DSVAのステータス確認
        • NSX 関連コンポーネントのステータス確認(NSX-V環境用)>Network Introspectionの状態確認(Webレピュテーション/ファイアウォール/侵入防御機能の利用時のみ)
        • ESXiコンポーネントのステータス確認>Webレピュテーション/ファイアウォール/侵入防御機能ご利用時
      3. DSVAの再起動([各コンポーネントの再起動方法]の項を参照ください)
      4. DSVAの再配信([DSVAの再配信方法]の項を参照ください)

    侵入防御などの機能を一度有効化し、オフラインエラーが発生した後機能を無効にしても侵入防御/ファイアウォールエンジンオフラインエラーがクリアできない場合があります。
    機能を無効化してもエンジンオフラインが消去できない場合、該当機能を無効にした後、一旦「Appliance保護の無効化」を実行し、その後再度「有効化」してください(この際、「再有効化」は選択しないでください)。

    ステータス:オフラインの解消方法

    DSVAはVMware側の複数のコンポーネントと密接に連携することにより動作しております。そのため、Deep Security側コンポーネントのみでエラーが発生している場合でもVMware側コンポーネントの設定や動作不良によって発生する可能性もございます。 そのため、「どのESXi上」で「何台中何台の仮想マシン」に「どのようなタイミング」で「何のアラート」が発生しているかを整理し障害点を洗い出すことがトラブルシュートのポイントとなります。

    対応Step一覧

    【Step1】問題発生対象の確認

    まずは「オフライン」アラートがどのESXi上で何台の仮想マシンで発生しているか、 製品Q&A:DSVA環境のトラブルシューティングステップ>「【Step1】問題発生対象」の確認をもとにパターンを分類し発生対象ESXiと仮想マシンを整理します。

    【Step2】トラブルシューティング

    整理した発生状況から以下のとおりトラブルシューティングを実施します。 DSMはハートビートによりAgentの死活を監視しています。 DSVA保護下の場合、仮想マシンはDeep Security 側コンポーネントと直接通信を行わなずVirtual Agentを管理しているDSVAがハートビートを実施します。 そのため、本項記載の「ステータス:オフライン」はVirtual Agent(仮想マシンの管理情報)を保有するDSVAと正常に通信を行えていない状態を表します。

    • 通信フロー上は以下図の通信2が該当します。(DSVA環境の通信フロー図の概要より抜粋)

    ※通信の詳細な解説は[DSVA環境の通信フロー]の項を参照ください

    • 特定 or 複数の仮想マシンのみで発生している場合

      要因

      • DSMが仮想マシンの配置情報を取得できていない
      • DSVAの保有するVirtual Agentが破損している

      対処法

      1. DSVA環境のトラブルシューティングステップ>【Step2】環境の正常性確認>「vCenter/NSX Manager同期確認」を参照しDSMとvCenter/NSX Managerとの同期を実施ください。

        実施後、「警告/エラーのクリア」、「ステータスの確認」にて事象が改善するかを確認ください。

      2. 改善しない場合、該当の仮想マシンで「無効化」を実行後、「有効化」を実行(再有効化ではなく、一旦無効化後の有効化を実施ください)

        無効化-再度有効化を行うことによりDSVA内の保護対象マシンごとの設定(Virtual Agent)が消去/再作成されます。


    • 1台のESXi上のすべての仮想マシンで発生している場合

      要因

      • 仮想マシンを管理しているDSVAが動作していない
      • DSVA自身のステータスがオフラインとなっている
      • DSVAがDSMの名前解決を出来ていない
      • DSM/DSVAの負荷が高い

      対処法

      1. DSVA環境のトラブルシューティングステップ>【Step2】環境の正常性確認>「vCenter/NSX Manager同期確認」を参照しDSMとvCenter/NSX Managerとの同期を実施ください。

        実施後、対象のDSVAにて「警告/エラーのクリア」、「ステータスの確認」にて事象が改善するかを確認ください。

      2. DSMにてハートビート拒否イベントが発生しているかを確認。詳細は製品Q&A:「Agent/Applianceのハートビートの拒否」イベントが発生するをご確認ください。

      3. 対象DSVAにログイン(ログイン方法は[DSVAへのログイン・SSHの有効化方法]を参照ください)

        • DSMへのハートビートをコマンドにて実施し、「HTTP Status:200 OK」が返ってくることを確認

          sudo /opt/ds_agent/dsa_control -m

        • 「HTTP Status:200 OK」以外の場合、DSVAがDSMの名前解決を行えているか確認(参考製品Q&A:[HowTo] DNS がない、または正しく構成されていない環境での運用方法

          ping "DSMのFQDN"

          ※nslookup,digコマンドは用意されてませんため、名前解決の確認にPingを使用します。

          >DSMのFQDNは[DSM管理コンソール]>[管理]>[Managerノード]から確認可能です。

           

          ※DSMが複数存在する環境の場合はすべてのDSMのFQDNに対して実施ください。

          [管理コンソール]>[管理]>[システム設定]>[詳細]にてロードバランサの設定をされている場合は設定されたFQDNに実施ください。

      4. DSMにて対象DSVAのポリシーを切り分けのためなしに設定(後で設定を戻してください)

      5. 対象DSVAの再起動を実施([各コンポーネントの再起動方法]を参照)

      6. 対象DSVAの再配信を実施([DSVAの再配信方法]を参照)

      7. 再発する場合は対象DSVAのリソースを追加

        DSVAの再起動、再配信によるリフレッシュにて改善し、事象が再発する場合は環境負荷が高い可能性がありますので改めて サイジングをご確認ください。なお、サイジング表上リソースが満たされている環境であっても使用状況によりましてはリソースが不足している可能性がございます。 そのため、再起動後に再発がされる場合は一時的にでもDSVAに設定されているCPUおよびメモリリソースを段階的に上げる(目安としてCPUの場合は6~8core程度、メモリの場合は12~16GB程度)ことで事象が改善するかをご確認ください。

      8. 改善が見られない場合、DSMの再起動を実施([各コンポーネントの再起動方法]を参照)

        DSMの使用する最大メモリ量は初期設定4GBとなっております。 こちらはインストールフォルダ内の「.vmoptions」ファイルにて調整が可能です(物理メモリが16GBなど搭載されている場合でも本ファイルに設定されております値が 最大値となります。詳細はDeep Security Managerのメモリ使用量の設定を参照ください)。 DSMの再起動後も時間の経過で再発する場合はメモリが不足している可能性がありますので、 サイジングをご確認いただき、最大メモリ量の調整を検討ください。 なお、複数台のDSMが存在する環境の場合は全台にて実施ください。

    DSVAが起動しない

    DSVAの起動時、起動が停止した場合は 製品Q&A:Deep Security Virtual Appliance の起動中にハングアップするを参照ください。

    セキュリティアップデートが失敗する

    セキュリティアップデートが失敗する場合は 製品Q&A:セキュリティアップデートが失敗する場合のトラブルシューティング方法 を参照ください。

    仮想マシンが起動しない

    Security VM(DSVA)が停止している場合、同ESXiホスト上の仮想マシンは起動することができないVMware製品の動作制約がございます。詳細は 製品Q&A:Deep Security Virtual Appliance が停止していると仮想マシンを起動することができない を参照ください。

    DSVAのvMotion可否

    Security VMであるDSVAとGuest Introspection VMは配信後別のESXiホストに移動することはできません。詳細は製品Q&A:DSVA や GI の vMotion/ストレージvMotion について を参照ください。

    NSX-T 2.5.X環境での利用に関して

    NSX-T 2.5.X環境ではVMware製品側の仕様変更により使用可能なDSVAのOVFファイルに制限がございます。またデプロイに際してOVFの展開のため別途httpサーバの構築が必要となる場合がございます。詳細は以下のドキュメントを参照ください。

    NSX-T 3.X環境での利用に関して

    NSX-T 3.X環境から、トランスポートゾーンオーバレイがDSVAの展開に必要となっております。詳細は以下のドキュメントを参照ください。

    製品Q&A:Overlay Transport Zone is required when deploying Trend Micro Deep Security with NSX-T

    NSX-V から NSX-T 3.0 以降のバージョンへの移行について

    NSX-V から NSX-T 3.0 以降のバージョンへの Deep Security Virtual Appliance (DSVA) の移行を計画されている場合は、以下のヘルプセンターのページを参考にご実施ください。

     

    なお、NSX-T Migration Coordinator を利用した移行は、DSVAの観点ではサポートされていません。
    詳細は以下の製品Q&A(英語)をご参照ください。

    DSVAの各ステータスがオンラインの状態で保護機能が動作していない

    DSVAのデプロイ後には指定されているソフトウェアアップグレードが実施されます。初期設定ではDSM/DSRにインポートされている最新のビルドにアップグレードされます(本動作の詳細はドキュメントを参照ください。 NSX-V環境はこちら、 NSX-T 3.0未満の環境は こちら、NSX-T 3.0以上の環境はこちら)。 なお、DSVAのOVFファイルをDSMにインポート後、自動的に使用するソフトウェアがインポートされます(詳細はこちら)。 例外としてオフラインの環境などでDSM/DSRにソフトウェアがインポートされていない場合、ソフトウェアアップグレード処理が行えず、デプロイ後のDSVAが正常に動作しない事象が発生いたします。詳細は以下製品Q&Aを参照ください。

    DSMとDSVAの通信時の名前解決

    通常DSMは管理下のコンピュータとの通信にDSM上で指定されたホスト名使用します。ホスト名にFQDNが指定されている場合は名前解決の結果のIPアドレスを、ホスト名にIPアドレスが指定されている場合はそのIPアドレスを使用します。 例外としてDSMがvCenterと同期されている場合、そのvCenter配下のコンピュータとの通信はこちらのホスト名ではなくvCenterから連携されたIPアドレスを使用します。DSVA環境ではこちらの例外の状態に該当します。詳細は以下のドキュメントを参照ください。

    パターンごとのDSMとvCenter/NSX Managerの同期方法について

    DSMにvCenter ServerおよびNSX-T/V Managerを同期する際、ご利用環境ごとにサポート可否の構成がございます。詳細は以下の製品Q&Aを参照ください。

    DSVA環境で「ディスク容量の不足」イベントが出力されます

    DSVAコンピュータで「ディスク容量の不足」イベントが出力され、アラート「〇台のコンピュータの空きディスク容量が不足しています」アラートが発令されます。また、/var/opt/ds_agent/diag/dsva/ds_monitor.logファイルがとても大きくなっています。詳細は以下の製品Q&Aを参照ください。

    Premium
    Internal
    Partner
    評価:
    カテゴリ:
    Configure; Troubleshoot; Deploy; Install
    Solution Id:
    000159761
    ご提案/ご意見
    このソリューションはお役に立ちましたか?

    フィードバックありがとうございました!


    *こちらに技術的なご質問などをいただきましてもご返答する事ができません.

    何卒ご了承いただきますようお願いいたします.


    To help us improve the quality of this article, please leave your email here so we can clarify further your feedback, if neccessary:
    We will not send you spam or share your email address.

    *This form is automated system. General questions, technical, sales, and product-related issues submitted through this form will not be answered.


    ユーザーガイド