目次
このページのトピック
原因
Agentが実行されていることを確認する
DNSを検証する
DNSサービスの信頼性を確認する
送信ポートを許可する (Agentからのハートビート)
Amazon AWS EC2インスタンスでICMPを許可する
Solaris 11でのアップグレードの問題を解決する

オフラインエージェント

コンピュータ status が [オフライン] または [管理対象 (オフライン)] の場合は、Workload Securityが一定期間エージェントのインスタンスと通信しておらず、ハートビート未送信のしきい値を超えたことを意味します。ステータスの変更は、アラートとイベントにも表示されます。

原因

ハートビート接続は、次の理由で失敗することがあります。

  • Agentは、シャットダウンしたワークステーションまたは他のコンピュータにインストールされます。コンピュータの電源を入れ直すと、次のハートビート間隔でエラーが解決されます。

  • ファイアウォール、IPSルール、またはセキュリティグループが、ハートビートポート番号をブロックしている。

  • 送信 (エフェメラル) ポートが誤ってブロックされた。トラブルシューティングのヒントについては、「Activation Failed - Blocked port」を参照してください。

  • 双方向通信は有効ですが、一方向のみが許可または信頼されます。

  • コンピュータの電源がオフになった。

  • コンピュータがプライベートネットワークの コンテキスト を終了しました。これは、移動先エンドポイント（ラップトップなど）が現在の場所で Workload Security に接続できない場合に発生します。たとえば、ゲストWi-Fiではオープンポートを制限することが多く、トラフィックがインターネットを通過するときにNATを使用します。

  • Amazon WorkSpaceコンピュータの電源がオフになっていて、ハートビート間隔が短い場合 (例: 1分)。この場合は、WorkSpaceの電源が完全にオフになるまで待ちます。その時点で、ステータスが [オフライン] から [仮想マシンの停止] に変わります。

  • DNSがダウンしていたか、Workload Securityホスト名が解決されていません。

  • Workload Security、エージェント、またはその両方がシステムリソースの負荷が非常に高い。

  • Agentプロセスが稼働していない可能性がある。

  • エージェントのシステム時間が正しくありません（SSL / TLS接続で必要です）。

  • ルールのアップデートはまだ完了していません。一時的に接続が中断されています。

  • AWS EC2で、ICMPトラフィックが必要だが、ブロックされている。

Managerからの通信または双方向の通信を使用していて、通信に問題がある場合は、Agentからの有効化に変更する必要があります Agentからの有効化と通信を使用したAgentの有効化と保護 を参照。エラーのトラブルシューティングを行うには、エージェントが実行されていること、およびAgentがWorkload Security (Manager) と通信できることを確認します。

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

エージェントが実行されていることを確認します。方法はオペレーティングシステムによって異なります。

  • 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を検証する

ドメイン名またはホスト名（IPアドレスではなく）を介してエージェントがWorkload Securityに接続する場合は、DNS解決をテストします。

nslookup [manager domain name]

DNSサービスの信頼性を確認する

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

コンピュータでDHCPを使用している場合は、コンピュータ設定またはポリシー設定の[ Advanced Network Engine ] 領域で、[ Force Allow DHCP DNS ] を有効にする必要がある場合があります (コンピュータとポリシーエディタの設定 を参照)。

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

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

telnet agents.deepsecurity.trendmicro.com:443

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

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

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

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

Workload Securityでこのトラフィックを強制的に許可できます。強制的に許可するファイアウォールポリシーを作成するか、コンピュータ設定またはポリシー設定の Advanced Network Engine 領域で、 Force Allow ICMP type3 code4 を有効にします (コンピュータとポリシーエディタの設定] を参照)。

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

以前にバージョン9.0のエージェントをSolaris 11にインストールし、その後9.0.0-5616以降の9.0のエージェントをインストールせずにエージェントソフトウェアを直接11.0にアップグレードした場合に、問題が発生することがあります。このシナリオでは、アップグレード後にエージェントが起動に失敗し、 Workload Securityでオフラインと表示されることがあります。この問題を解決するには、次の手順に従います。

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