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

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

オフラインエージェント

オフラインまたは管理対象 (オフライン) のコンピュータステータスは、Deep Security ManagerがDeep Securityエージェントのインスタンスとしばらく通信しておらず、ハートビートのしきい値を超えたことを意味します (ハートビートを設定するを参照)。ステータスの変更は、アラートやイベントにも表示されることがあります。

原因

ハートビート接続が失敗する理由は次のとおりです:

  • エージェントは、シャットダウンされたワークステーションまたは他のコンピュータにインストールされています。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からの通信または双方向の通信で問題が発生した場合は、Agentからのリモート有効化に変更する必要があります (Agentからのリモート有効化およびAgentからの通信を使用して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サービスは信頼できる必要があります。

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

コンピュータがDHCPを使用している場合、コンピュータまたはポリシー設定の高度なネットワークエンジンエリアでDHCP DNSの強制許可を有効にする必要があるかもしれません (ネットワークエンジン設定を参照)。

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

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

telnet [manager IP]:4120

Telnetの成功は、pingと同じことのほとんどを証明します: ルートと正しいファイアウォールポリシーが存在し、イーサネットフレームサイズが正しいことです。マネージャのデフォルトのセキュリティポリシーを使用しているコンピュータでは、pingが無効になっています。ネットワークは、攻撃者の攻撃の予兆スキャンをブロックするために、ICMP pingおよびtracerouteをブロックすることがあります。したがって、通常、マネージャをテストするためにpingを使用することはできません。

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

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

    traceroute [agent IP]

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

    tracert [agent IP]

ファイアウォールポリシー、ルート、NATポートフォワーディング、またはそのすべてを調整して問題を修正してください。WindowsファイアウォールやLinuxのiptablesなど、ネットワークおよびホストベースのファイアウォールの両方を確認してください。AWS EC2インスタンスの場合は、AmazonのドキュメントAmazon EC2 Security Groups for Linux InstancesまたはAmazon EC2 Security Groups for Windows Instancesを参照してください。Azure VMインスタンスの場合は、Microsoft AzureのドキュメントModifying a Network Security Groupを参照してください。

エージェントからマネージャへの接続テストが成功した場合、次に逆方向の接続テストを行う必要があります (ファイアウォールやルーターは、接続を許可するためにポリシールートのペアを必要とすることがよくあります。必要な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エージェント9.0をインストールし、その後9.0.0-5616またはそれ以降の9.0エージェントをインストールせずにエージェントソフトウェアを直接11.0にアップグレードした場合、問題が発生する可能性があります。このシナリオでは、アップグレード後にエージェントが起動に失敗し、Deep Security Managerでオフラインとして表示されることがあります。この問題を解決するには:

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