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

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

「オフライン」のAgent

Managerで設定した失われたハートビートのしきい値を超えると、コンピュータのステータスが「オフライン」または「管理対象 (オフライン)」に変わります。この状況はアラートとイベントにも示されます。

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

コンピュータの電源がオフになった。
コンピュータがプライベートネットワークのコンテキスト外に移動した。
この状況は、オンプレミスのDeep Security Managerを使用していて、エンドポイント (ノートパソコンなど) がインターネット経由でプライベートな社内ネットワーク上のManagerに接続できない場合に発生します。
Amazon WorkSpaceのコンピュータの電源をオフにしようとしていて、ハートビート間隔が短い (1分など)。この場合、WorkSpaceの電源がオフになるまで待ちます。オフになった時点でステータスは「オフライン」から「仮想マシン停止」になります。
DNSが停止したか、Managerのホスト名を解決できなかった。
ファイアウォール、IPSルール、またはAWSセキュリティグループが、ハートビートポート番号をブロックしている。
双方向通信が有効になっているが、許可されている、または安定しているのが一方向のみである。
Deep Security ManagerかAgent、またはその両方で、システムリソースの負荷が非常に高い。
Deep SecurityAgentプロセス (Windowsではds_agentサービス) が稼働していない可能性がある。
SSLまたはTLS接続の相互認証用証明書が無効になったか失効した、あるいはシステム時間が正しくない。
Deep Security のルールアップデート中で、接続が一時的に中断している。

Managerからの通信または双方向の通信で問題が発生した場合は、Agentからのリモート有効化に変更することを強く推奨します (クラウドアカウント環境の通信方向を参照)。

サービス、ルート、およびポート番号を調べて、Deep Security Agentが実行されていること、およびDeep Security Managerと通信できることを確認します。

Deep Security Agentがインストールされたコンピュータで、Trend Micro Deep Security Agentサービスが実行されていることを確認します。方法はOSによって異なります。
- Windowsの場合は、Microsoft Windowsサービスコンソール (services.msc) またはタスクマネージャーを開きます。
- Linuxの場合は、ターミナルを開き、次のようなプロセスをリストするコマンドを入力します。
  
  sudo ps -aux | grep ds_agent
  
  sudo service ds_agent status
AgentがIPアドレスではなくドメイン名またはホスト名でDeep Security Managerに接続する場合は、DNS解決をテストします。

nslookup [Managerのドメイン名]

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

telnet [ManagerのIP]:[ハートビートポート]

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

一方telnetが失敗した場合は、いくつかの原因が考えられます。原因を迅速に突き止めるために、トラブルシューティングの間はpingとICMPトラフィックを一時的に有効にすることができます。

telnetが失敗した場合は、ルートをトレースして、ネットワークのどのポイントで接続が中断されているかを特定します。方法はOSによって異なります。
- Linuxの場合は次のコマンドを入力します。
  
  traceroute [AgentのIP]
- Windowsの場合は次のコマンドを入力します。
  
  tracert [AgentのIP]
ファイアウォールポリシー、ルート、NATポート転送、またはこの3つすべてを調整して問題を解決します。

AgentからManagerへの接続テストが成功したら、次に逆方向の接続をテストする必要があります。(ファイアウォールおよびルータでは、1組のポリシー/ルートがないと接続が許可されないことがよくあります。2つ必要なポリシーまたはルートのうち1つしか存在しない場合は、一方向のパケットだけが許可され、逆方向は許可されません)。
Deep Security ManagerからDeep Security Agentにpingを実行し、ハートビートポート番号にtelnetで接続して、ハートビートと設定のトラフィックがAgentに到達できることを確認します。

ping [AgentのIP]

telnet [AgentのIP]:[ハートビートポート]

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

traceroute [AgentのIP]

これによって、ネットワークのどのポイントで接続が中断されているかを検出します。ファイアウォールポリシー、ルート、NATポート転送、またはこの3つすべてを調整して問題を解決します。
IPSルールまたはファイアウォールルールがDeep Security AgentとDeep Security Managerの間の接続をブロックしている場合は、Deep Security Agentで次のコマンドを実行します。

dsa_control -r

これによって、Deep Security Agent上のポリシーがリセットされます。この場合、AgentのセキュリティによってDeep Security Managerとの通信がブロックされているために、Managerが接続して問題の原因であるポリシーを割り当て解除することができません。

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