本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。

本ヘルプセンターの一部の記事には外部リンクが含まれています。万一リンク切れなどお気づきの点がございましたら、お手数ですが弊社サポート窓口までご連絡ください。

「オフライン」のAgent

コンピュータのステータスが [オフライン] または [管理対象 (オフライン)] の場合、Deep Security ManagerはDeep Security Agentのインスタンスとしばらく通信していない状態で、失われたハートビートのしきい値を超過しています。(ハートビートを設定するを参照してください)。このステータスの変化はアラートおよびイベントにも示されます。

原因

ハートビート接続が失敗する原因としては次のことが考えられます。

  • Agentは、シャットダウンしたワークステーションまたは他のコンピュータにインストールされます。Deep Securityを使用してシャットダウンされることがあるコンピュータを保護している場合、これらのコンピュータに割り当てられたポリシーは、ハートビートが失われたときにアラートを発令しません。ポリシーエディタで、[設定]→[一般]→[次の数を超えるハートビートが失われた場合にアラートを発令] に移動し、設定を [無制限] に変更します。
  • ファイアウォール、IPSルール、またはセキュリティグループが、ハートビートポート番号をブロックしている。
  • 送信 (エフェメラル) ポートが誤ってブロックされた。トラブルシューティングのヒントについては、ブロックされたポートを参照してください。
  • 双方向通信が有効になっているが、許可されている、または安定しているのが一方向のみである(通信方向を設定するを参照)。
  • コンピュータの電源がオフになった。
  • コンピュータがプライベートネットワークのコンテキスト外に移動した。
    この状況は、ローミングを使用しているエンドポイント (ノートパソコンなど) が現在の場所でManagerに接続できない場合に発生します。たとえば、ゲストWi-Fiではオープンポートを制限することが多く、トラフィックがインターネットを通過するときにNATを使用します。
  • Amazon WorkSpaceコンピュータの電源がオフになり、ハートビートの間隔が高速（1分など）になる。この場合、WorkSpaceの電源が完全にオフになるのを待ってください。その時点で、ステータスは「オフライン」から「VM停止」に変わります。
  • DNSが停止したか、Managerのホスト名を解決できなかった。
  • Manager、Agent、またはその両方で、システムリソースの負荷が非常に高い。
  • Agentプロセスが稼働していない可能性がある。
  • SSLまたはTLS接続の相互認証用証明書が無効になったか失効した (Deep Security ManagerのTLS証明書を変更します。を参照)。
  • エージェントまたはマネージャのシステム時間が正しくありません（SSL/TLS接続で必要です）。
  • Deep Securityルールのアップデートがまだ完了していないため、一時的に接続が中断される。
  • AWS EC2で、ICMPトラフィックが必要だが、ブロックされている。
  • エージェントをバージョン20.0.0.6313以降にアップグレードした後、エージェントが引き続きSHA-1アルゴリズムを使用している場合。これで、エージェントはManagerとの通信に、より安全な新しい暗号化アルゴリズムのみを許可します。
Managerからの通信または双方向の通信で問題が発生した場合は、Agentからのリモート有効化に変更することを強く推奨します (Agentからのリモート有効化およびAgentからの通信を使用してAgentを有効化して保護するを参照)。

エラーをトラブルシューティングするには、Agentが実行されていること、およびManagerと通信できることを確認します。

Agentが実行されていることを確認する

Agentがインストールされたコンピュータで、Trend Micro Deep Security Agentサービスが実行されていることを確認します。方法はOSによって異なります。

  • Windowsの場合は、Microsoft Windowsサービスコンソール (services.msc) またはタスクマネージャーを開きます。ds_agentという名前のサービスを探します。

  • Linuxの場合は、ターミナルを開き、プロセスをリストするコマンドを入力します。次のコマンドを実行して、ds_agentまたはds-agentという名前のサービスを検索します。

    sudo ps -aux | grep ds_agent

    sudo service ds_agent status

  • Solarisの場合は、ターミナルを開き、プロセスをリストするコマンドを入力します。次のコマンドを実行して、ds_agentという名前のサービスを検索します。

    sudo ps -ef | grep ds_agent

    sudo svcs -l svc:/application/ds_agent:default

DNSを検証する

AgentがIPアドレスではなくドメイン名またはホスト名でManagerに接続する場合は、DNS解決をテストします。

nslookup [manager domain name]

DNSサービスは信頼できるものでなければなりません。

テストが失敗した場合は、Agentが正しいDNSプロキシまたはDNSサーバを使用していることを確認します (GoogleやISPなどのパブリックDNSサーバでは内部ドメイン名を解決できません)。IPアドレスに正しいルートとファイアウォールポリシーが設定されていても、dsm.example.comなどの名前をIPアドレスに解決できないと、通信は失敗します。

[ネットワークエンジンの詳細] 領域のコンピュータまたはポリシー設定で、コンピュータがDHCPを使用している場合は、[DHCP DNSを強制的に許可] の有効化が必要になる場合があります (ネットワークエンジン設定を参照)。

送信ポートを許可する (Agentからのハートビート)

Managerの必要なポート番号にtelnetで接続して、ルートが存在し、ポートが開いていることを確認します。

telnet [manager IP]:4120

telnetの成功はpingの成功とほぼ同意味を持ち、ルートと正しいファイアウォールポリシーが存在すること、およびEthernetフレームサイズが正しいことを示しています(Managerの初期設定のセキュリティポリシーを使用するコンピュータでは、pingが無効になっています。攻撃者による予兆検索を阻止するためにネットワークがICMP pingとtracerouteをブロックすることがあるため、通常はManagerへpingを実行してテストすることはできません)。

telnetが失敗した場合は、ルートをトレースして、ネットワークのどのポイントで接続が中断されているかを特定します。

  • Linuxの場合は次のコマンドを入力します。

    traceroute [agent IP]

  • Windowsの場合は次のコマンドを入力します。

    tracert [agent IP]

ファイアウォールポリシー、ルート、NATポート転送、またはこれら3つすべてを調整して、問題を解決します。WindowsファイアウォールやLinuxのiptablesなど、ネットワークおよびホストベースのファイアウォールの両方を確認します。AWS EC2インスタンスの場合は、Amazonのドキュメントの「Linux インスタンスの Amazon EC2 セキュリティグループ」または「Windows インスタンスの Amazon EC2 セキュリティグループ」を参照してください。Azure VMインスタンスについては、 のMicrosoft社のAzureドキュメント（ Network Security グループの変更）を参照してください。

AgentからManagerへの接続テストが成功したら、次に逆方向の接続をテストする必要があります(ファイアウォールおよびルータでは、1組のポリシー/ルートがないと接続が許可されないことがよくあります。2つ必要なポリシーまたはルートのうち1つしか存在しない場合は、一方向のパケットだけが許可され、逆方向は許可されません)。

受信ポートを許可する (Managerからのハートビート)

ManagerからAgentにpingを実行し、ハートビートポート番号にtelnetで接続して、ハートビートと設定のトラフィックがAgentに到達できることを確認します。

ping [agent IP]

telnet [agent IP]:4118

pingとtelnetが失敗した場合は、次のコマンドを実行します。

traceroute [agent IP]

これによって、ネットワークのどのポイントで接続が中断されているかを検出します。ファイアウォールポリシー、ルート、NATポート転送、またはこれら3つすべてを調整して、問題を解決します。

IPSルールまたはファイアウォールルールがAgentとManagerの間の接続をブロックしている場合は、Managerが接続して問題の原因であるポリシーを割り当て解除することができません。解決するには、コンピュータで次のコマンドを実行してAgentのポリシーをリセットします。

dsa_control -r

このコマンドを実行した後に、Agentを再び有効化する必要があります。

Amazon AWS EC2インスタンスでICMPを許可する

AWSクラウドでは、ルータにICMP type3 code4が必要です。このトラフィックがブロックされていると、AgentとManager間の接続が中断される場合があります。

Deep Securityで強制的にこのトラフィックを許可できます。強制的に許可するファイアウォールポリシーを作成するか、コンピュータまたはポリシーの [ネットワークエンジンの詳細オプション] で、[ICMP type3 code4を強制的に許可] を有効にします (ネットワークエンジン設定を参照)。

Solaris 11でのアップグレードの問題を解決する

Solaris 11にDeep Security Agent 9.0がインストールされている場合、先に9.0.0-5616以降の9.0 AgentをインストールせずにAgentソフトウェアを11.0へ直接アップグレードすると、問題が発生することがあります。このようなシナリオでは、アップグレード後にAgentが起動しなくなり、Deep Security Managerでオフラインと表示されることがあります。この問題を解決するには、次の手順に従います。

  1. サーバからAgentをアンインストールします。Deep Security Agentをアンインストールするを参照してください。
  2. Deep Security Agent 11.0をインストールします。 エージェントを手動でインストールする。
  3. ManagerでAgentを再有効化します。Agentの有効化を参照してください。