Deep Security 11のサポートは終了しています。バージョンセレクタ（上記）を使用して、より新しいバージョンのヘルプセンターを表示します。

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

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

「オフライン」のAgent

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

原因

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

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

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

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

Deep Security 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アドレスではなくドメイン名/ホスト名でDeep Security Managerに接続する場合は、名前解決をテストします。

nslookup [Managerのドメイン名]

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

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

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

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

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

telnet [managerのIP]:4120

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

• 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 Groupの変更を参照してください。

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

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

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

ping [AgentのIP]

telnet [AgentのIP]:4118

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

traceroute [AgentのIP]

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

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

dsa_control -r

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をインストールします。SolarisにAgentをインストールするを参照してください。
3. ManagerでAgentを再有効化します。Agentの有効化を参照してください。