コンピュータステータス「オフライン」または「管理対象 (オフライン)」の場合は、 Server & Workload Protection が一定期間エージェントのインスタンスと通信しておらず、ハートビート未送信のしきい値を超えていることを意味します。ステータスの変更は、アラートとイベントにも表示されます。
原因
ハートビート接続が失敗する原因としては次のことが考えられます。
-
エージェントが、シャットダウンされているワークステーションまたはその他のコンピュータにインストールされている。コンピュータの電源を入れ直すと、次のハートビート間隔でエラーが解決されます。
-
ファイアウォール、IPSルール、またはセキュリティグループがハートビートをブロックするポート番号。
-
送信 (エフェメラル) ポートが誤ってブロックされました。参照アクティベーション失敗 - ポートがブロックされましたを参照してください。
-
双方向通信が有効ですが、許可または信頼できるのは一方向のみです。
-
コンピュータの電源がオフになっています。
-
コンピュータがコンテキストプライベートネットワークのこれは、ローミングエンドポイント (ラップトップなど) が現在の場所にある Server & Workload Protection に接続できない場合に発生します。たとえば、ゲストWi-Fiでは、多くの場合、開いているポートが制限され、トラフィックがインターネットを通過するときにNATが適用されます。
-
Amazon WorkSpaceコンピュータの電源がオフになっていて、ハートビート間隔が短い場合 (例: 1分)。この場合は、WorkSpaceの電源が完全にオフになるまで待ちます。その時点で、ステータスが「オフライン」から「仮想マシン停止」に変わります。
-
DNSがダウンしているか、 Server & Workload Protection ホスト名を解決できませんでした。
-
Server & Workload Protection、エージェント、またはその両方のシステムリソース負荷が非常に高くなっています。
-
エージェントプロセスが実行されていない可能性があります。
-
エージェントのシステム時刻が正しくありません (SSL/TLS接続に必要)。
-
ルールアップデートはまだ完了していないため、接続が一時的に中断されます。
-
AWS EC2では、ICMPトラフィックが必要ですが、ブロックされます。
ヒントManagerからの通信または双方向の通信を使用していて、通信に問題がある場合は、Agentからの有効化に変更することを強くお勧めします (「 Agentからの有効化と通信を使用したAgentの有効化と保護)。エラーのトラブルシューティングを行うには、 エージェントが実行されていること、およびAgentが Server & Workload Protection (Manager)と通信できることを確認します。
|
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を検証する
エージェントがIPアドレスではなくドメイン名またはホスト名を使用して Server & Workload Protection に接続する場合は、DNS解決をテストします。
nslookup [manager domain name]
[DNSサービスは信頼できるものである必要があります。]
テストに失敗した場合は、エージェントが正しいDNSプロキシまたはサーバを使用していることを確認します (内部ドメイン名は、GoogleやISPなどのパブリックDNSサーバでは解決できません)。
dsm.example.comなどの名前をIPアドレスに解決できない場合、そのIPアドレスに対する正しいルートとファイアウォールポリシーが存在しても、通信は失敗します。
コンピュータでDHCPを使用している場合は、コンピュータ設定またはポリシー設定で、
Advanced Network Engine
有効にする必要がある場合がありますForce Allow DHCP DNS
(コンピュータとポリシーエディタの設定)。送信ポートを許可する (Agentからのハートビート)
Telnet必要なポート番号Managerで、ルートが存在し、ポートが開いていることを確認します。
telnet agents.deepsecurity.trendmicro.com:443
telnetが失敗した場合は、ルートをトレースして、ネットワークのどのポイントで接続が中断されているかを特定します。
ファイアウォールポリシー、ルート、NATポート転送、またはこれら3つすべてを調整して、問題を解決します。ネットワークおよびホストベースのファイアウォール (WindowsファイアウォールやLinux
iptablesなど) の両方を確認します。 AWS EC2インスタンスについては、 Linuxインスタンス用Amazon EC2セキュリティグループまたはWindowsインスタンス用Amazon EC2セキュリティグループ。 Azure VMインスタンスについては、ネットワークセキュリティグループの変更。
Amazon AWS EC2インスタンスでICMPを許可する
AWSクラウドでは、ルータにICMP type3 code4が必要です。このトラフィックがブロックされていると、AgentとManager間の接続が中断される場合があります。
Server & Workload Protectionでこのトラフィックを強制的に許可できます。強制的に許可するファイアウォールポリシーを作成するか、コンピュータ設定またはポリシー設定の [高度なネットワークエンジン] 領域で [ICMP type3 code4を強制的に許可] を有効にします (「コンピュータとポリシーエディタの設定)。
Solaris 11でのアップグレードの問題を修正する
以前にSolaris 11にバージョン9.0のエージェントをインストールし、9.0.0-5616以降のエージェントをインストールせずにエージェントソフトウェアを11.0に直接アップグレードすると、問題が発生することがあります。このシナリオでは、アップグレード後にエージェントが起動できず、
Server & Workload Protectionでオフラインとして表示されることがあります。この問題を解決するには
手順
- サーバからエージェントをアンインストールします。参照Server & Workload Protection Agentのアンインストール。
- 11.0エージェントをインストールします。参照エージェントを手動でインストールする。
- Server & Workload Protectionでエージェントを再度有効にします。参照エージェントの有効化。