ログ ファイル：

ログファイルは、<install-location>/logs または <install-location>/log フォルダに保存されます。ログファイルは、Secure Workload サービスを通じてモニターおよびローテーションされます。

エージェントの展開

Linux

rpm -Uvh tet-sensor-1.101.2-1.el6-dev.x86_64.rpm

   error: cannot create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied).

A：エージェントをインストールするための適切な権限がない場合は、root に切り替えるか、sudo を使用してエージェントをインストールしてください。

Q：「sudo rpm -Uvh tet-sensor-1.0.0-121.1b1bb546.el6-dev.x86_64.rpm」を実行すると、次のエラーが発生しました。

   Preparing...              ########################################### [100%]
   which: no lsb_release in (/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin)
   error: %pre(tet-sensor-site-1.0.0-121.1b1bb546.x86_64) scriptlet failed, exit status 1
   error:   install: %pre scriptlet failed (2), skipping tet-sensor-site-1.0.0-121.1b1bb546

A：システムはエージェントをインストールするための要件を満たしていません。今回のケースでは、lsb_release ツールはインストールされていません。

詳細については、「ソフトウェアエージェントの展開ラベル」の項を参照し、必要な依存関係をインストールしてください。

Q：「sudo rpm -Uvh tet-sensor-1.0.0-121.1b1bb546.el6-dev.x86_64.rpm」を実行すると、次のエラーが発生しました。

  Unsupported OS openSUSE project
  error: %pre(tet-sensor-1.101.1-1.x86_64) scriptlet failed, exit status 1
  error: tet-sensor-1.101.1-1.x86_64: install failed
  warning: %post(tet-sensor-site-1.101.1-1.x86_64) scriptlet failed, exit status 1

A：お使いの OS では、ソフトウェアエージェントの実行がサポートされていません（今回のケースでは、「openSUSE project」はサポートされていないプラットフォームです）。

詳細については、「ソフトウェアエージェントの展開ラベル」の項を参照してください。

Q：すべての依存関係をインストールした後、適切な権限でインストールを実行し、エラーは発生しませんでした。エージェントのインストールが成功したことを確認するにはどうすればよいですか。

A：エージェントをインストールした後、インストールされているかどうかを確認するには、次のコマンドを実行します。

$ ps -ef | grep -e csw-agent -e tet-
root     14158     1  0 Apr03 ?        00:00:00 csw-agent
root     14160 14158  0 Apr03 ?        00:00:00 csw-agent watch_files
root     14161 14158  0 Apr03 ?        00:00:03 csw-agent check_conf
root     14162 14158  0 Apr03 ?        00:01:03 tet-sensor -f conf/.sensor_config
root     14163 14158  0 Apr03 ?        00:02:38 tet-main --sensoridfile=./sensor_id
root     14164 14158  0 Apr03 ?        00:00:22 tet-enforcer --logtostderr
tet-sen+ 14173 14164  0 Apr03 ?        00:00:21 tet-enforcer --logtostderr
tet-sen+ 14192 14162  0 Apr03 ?        00:07:23 tet-sensor -f conf/.sensor_config

csw-agent の 3 つのエントリと、tet-sensor の少なくとも 2 つのエントリが表示されている必要があります。サービスが実行されていない場合は、次のディレクトリが使用可能であることを確認します。使用可能でない場合、インストールは失敗します。

• /usr/local/tet（ほとんどの Linux ディストリビューションの場合）

• /opt/cisco/tetration（AIX、Ubuntu の場合）

• /opt/cisco/secure-workload（Solaris、Debian の場合）

Windows

Q：PowerShell エージェント インストーラ スクリプトを実行すると、次のいずれかのエラーが表示されます。

1. 基礎となる接続がクローズしました。受信時に予期せぬエラーが発生しました。

2. 共通のアルゴリズムがないため、クライアントとサーバーが通信できません

[Net.ServicePointManager]::SecurityProtocol

[Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]’Ssl3,Tls,Tls11,Tls12’

This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.

msiexec /i “TetrationAgentInstaller.msi” /l*v “msi_install.log” /norestart

Q：基盤となる NIC が Nutanix VirtIO ネットワークドライバの場合、Windows Sensor ソフトウェアのアップグレードに失敗するようです。

A：Npcap 0.9990 と、Nutanix VirtIO ネットワークドライバ 1.1.3 以前のバージョンの間には、非互換性の問題があります。また、Receive Segment Coalescing が有効になっています。

この問題を解決するには、Nutanix VirtIO ネットワークドライバをバージョン 1.1.3 以降にアップグレードします。

Q：Windows Sensor をインストールしました。そのセンサーが登録されていないようであり、sensor_id ファイルには uuid-invalid-platform が含まれています。

set PATH=%PATH%;C:\Windows\System32\

Q：Windows ノードの Kubernetes ポッドからネットワークフローを受信していません。

A：Windows ノードの Kubernetes ポッドからフローをキャプチャするために必要なセッションが実行されているか確認するには、次の手順を実行します。

1. 管理者権限で cmd.exe を実行します。

2. logman query -ets コマンドを実行します。

   次のセッションが実行されていることを確認します。

   • CSW_MonNet：ネットワークフローをキャプチャ

   • CSW_MonHCS：ポッドの作成をモニター

   • CSW_MonNat：NATed フローをモニター

Kubernetes

Kubernetes Daemonset のインストール中にインストーラスクリプトが失敗する場合、多くの理由が考えられます。

Q：ノードから到達可能なイメージを提供する Docker レジストリはありますか。

A：Cisco Secure Workload クラスタからイメージをプルするクラスタに関するダイレクトまたは HTTPS プロキシの問題をデバッグします。

Q：コンテナランタイムは SSL/TLS の安全でないエラーを報告していますか。

A：コンテナランタイムの適切な場所にあるすべての Kubernetes ノードに、Secure Workload HTTPS CA 証明書がインストールされていることを確認します。

Q：Docker レジストリ認証とイメージダウンロードの許可が失敗しましたか。

A：各ノードから、Helm チャートによって作成されたシークレットからの Docker プルシークレットを使用して、Daemonset 仕様のレジストリ URL から Docker が手動でイメージをプルするようにしてみてください。手動でのイメージプルも失敗した場合は、問題をさらにデバッグするため、Secure Workload クラスタの registryauth サービスからログをプルする必要があります。

Q：Kubernetes クラスタは Secure Workload アプライアンス内で正常にホストされていますか。

A：クラスタの [サービスステータス（service status）] ページをチェックして、関連するすべてのサービスが正常であることを確認します。[探索（explore）] ページから dstool スナップショットを実行し、生成されたログを取得します。

Q：Docker イメージビルダデーモンは実行されていますか。

A：dstool ログから、ビルドデーモンが実行されていることを確認します。

Q：Docker イメージをビルドするジョブは失敗しますか。

A：dstool ログから、イメージがビルドされていないことを確認します。Docker ビルドポッドログを使用して、ビルドキットを構築中のエラーをデバッグできます。適用コーディネータのログを使用して、ビルドの失敗をさらにデバッグすることも可能です。

Q：Helm チャートを作成するジョブは失敗しますか。

A：dstool ログから、Helm チャートが構築されていないことを確認します。適用コーディネータのログには Helm 構築ジョブの出力が含まれます。Helm チャートの構築ジョブの失敗の正確な理由をデバッグするために使用できます。

Q：インストール bash スクリプトが壊れていましたか。

A：インストール bash スクリプトのダウンロードを再試行します。bash スクリプトには、追加のバイナリデータが含まれています。bash スクリプトをテキストエディタで編集したり、テキストファイルとして保存したりすると、バイナリデータの特殊文字がテキストエディタによって破損または変更される可能性があります。

Q：Kubernetes クラスタ設定：亜種とフレーバーが多すぎます。クラシック K8 をサポートしています。

A：お客様が Kubernetes の亜種を実行している場合、展開のさまざまな段階で多くの障害モードが発生する可能性があります。失敗の段階を分類します： kubectl コマンド実行の失敗、helm コマンド実行の失敗、ポッドイメージのダウンロードの失敗、ポッドの特権モードオプションの拒否、ポッドイメージの信頼コンテンツ署名の失敗、ポッドイメージのセキュリティスキャンの失敗、ポッドバイナリ実行の失敗（アーキテクチャの不一致）、ポッドを実行しても Secure Workload サービスの開始が失敗、Secure Workload サービスが開始しても異常な動作環境が原因でランタイムエラーが発生。

Q：Kubernetes RBAC 資格情報が失敗していますか。

A：特権 DaemonSet を実行するには、K8s クラスタに対する管理者権限が必要です。kubectl 設定ファイルに、ターゲットクラスタおよびそのクラスタの管理者と同等のユーザーを指すデフォルトのコンテキストがあることを確認します。

Q：BusyBox イメージは、すべてのクラスタノードから利用可能またはダウンロード可能ですか。

A：接続の問題を修正し、BusyBox イメージがダウンロードできることを手動でテストします。ポッド仕様で使用されている BusyBox の正確なバージョンは、すべてのクラスタノードで使用可能（事前シード済み）またはダウンロード可能である必要があります。

Q：インストール中に、API サーバーおよび etcd エラーまたは通常のタイムアウトが発生しましたか。

A：Kubernetes クラスタ内のすべてのノードで DaemonSet ポッドがインスタンス化されるため、クラスタの CPU/ディスク/ネットワークの負荷が突然スパイクする可能性があります。この問題は、お客様固有のインストールの詳細に大きく依存します。過負荷が原因で、インストールプロセス（すべてのノードでプルされてディスクに書き込まれるイメージ）に時間がかかりすぎたり、Kubernetes API サーバー、または Secure Workload Docker レジストリエンドポイントが過負荷になったり、プロキシサーバー（設定されている場合）が一時的に過負荷になったりする可能性があります。すべてのノードでイメージのプルが完了し、Kubernetes クラスタノードの CPU/ディスク/ネットワークの負荷が軽減されるのを少し待ってから、インストールスクリプトを再試行します。API サーバーと Kubernetes コントロールプレーンからの etcd エラーは、Kubernetes コントロールプレーンノードがアンダープロビジョニングであるか、アクティビティの突然のスパイクの影響を受けている可能性があることを示しています。

Q：Secure Workload エージェントの操作でランタイムの問題が発生していますか。

A：ポッドが正しく展開され、エージェントの実行が開始されているが、ランタイムの問題が発生している場合は、Linux エージェントのトラブルシューティング セクションを参照してください。Kubernetes の展開が正常にインストールされ、ポッドが開始された後のトラブルシューティング手順は同じです。

異常タイプ

これらは、Secure Workload エージェントの使用および管理時にワークフローで発生する最も一般的な問題です。

非アクティブなエージェント

エージェントによるクラスタサービスへのチェックが停止しています。この現象は次のような原因で発生する可能性があります。

• ホストがダウンしている可能性がある

• ネットワーク接続が壊れているか、ファイアウォールルールによってブロックされている

• エージェントサービスが停止している

すべてのプラットフォームで次のことを確認します。

• ホストがアクティブで正常であることを確認します

• エージェントサービスが稼働状態であることを確認します

• クラスタへのネットワーク接続が機能していることを確認します

アップグレードの失敗

エージェントのアップグレードに失敗しました。これは、次のようないくつかのケースでトリガーされます。

• チェックインスクリプトがパッケージのダウンロードを試行したときにパッケージが見つからない - アップグレードパッケージを解凍できないか、パッケージ内のインストーラを検証できません。

• OS の問題または依存関係によるインストールプロセスの失敗。

Windows

• CA ルート証明書が存在しない：証明書の問題

• エージェントが最初に MSI インストールパッケージを使用して手動でインストールされた場合は、ユーザーガイドの「プラットフォームが現在サポートさているかどうかの確認」で、Windows エディションがサポートされているプラットフォームのリストと一致するかどうかを確認します。

• OS が Windows インストーラ操作用に正しく構成されていることを確認します：Windows インストーラの問題

• ホストに十分な空きディスク領域があることを確認します。

Linux

• 最後のエージェントのインストール以降にホスト OS がアップグレードされている場合は、ユーザーガイドの「プラットフォームが現在サポートさているかどうかの確認」で、現在のリリースがサポートされているプラットフォームのリストと一致していることを確認します。

• 前回のインストール以降、必要な依存関係が変更されていないことを確認します。これらの依存関係を再確認するには、-no-install オプションを指定してエージェント インストーラ スクリプトを実行します。

• ホストに十分な空きディスク領域があることを確認します。

AIX

• 前回のインストール以降、必要な依存関係が変更されていないことを確認します。これらの依存関係を再確認するには、-no-install オプションを指定してエージェント インストーラ スクリプトを実行します。

• ホストに十分な空きディスク領域があることを確認します。

コンバート失敗

現在のエージェントタイプが目的のエージェントタイプと一致しないため、コンバートの試行がタイムアウトしました。この問題は、エージェントがパッケージをダウンロードするために check_in を実行したとき、または wss サービスが convert_commnad をエージェントにプッシュできなかったときに、通信の問題が原因で発生する可能性があります。

すべてのプラットフォームに対して、ユーザー ガイドの「プラットフォームが現在サポートされているかどうかの確認」で、現在のリリースおよびエージェント タイプが、サポートされているプラットフォームのリストと一致していることを確認します。

機能の変換

エージェントをあるタイプ（優れた可視性など）から別のタイプ（適用など）に変換する能力は、すべてのエージェントが利用できるわけではありません。変換を実行できないエージェントで変換が要求された場合、異常が報告されます。

同期されていないポリシー

エージェントによって最後に報告された現在のポリシー（NPC）バージョンが、クラスターで生成された現在のバージョンと一致しません。これは、エージェントとクラスタ間の通信エラー、エージェントがローカルファイアウォールでポリシーを適用できない、またはエージェントの適用サービスが実行されていないことが原因である可能性があります。

Windows

• 適用モードが WAF の場合、ファイアウォールの有効化、ルールの追加（ルールの保持をオフの状態で）、またはデフォルトアクションの設定を妨げる GPO がホストに存在しないことを確認します。GPO の設定

• ホストとクラスタの間に接続があることを確認します。SSL のトラブルシューティング

• 生成されたルール数が 2000 未満であることを確認します。

• WindowsAgentEngine サービスが実行されていることを確認します。sc query windowsagentengine

• 利用可能なシステムリソースがあることを確認します。

Linux

• iptables および ipset コマンドを使用して、iptables および ipset が存在することを確認します。

• ホストとクラスタの間に接続があることを確認します。SSL のトラブルシューティング

• tet-enforcer プロセスが実行されていることを確認します。ps -ef | grep tet-enforcer

AIX

• ipf -V コマンドを使用して、ipfilter がインストールされ、実行されていることを確認します。

• ホストとクラスタの間に接続があることを確認します。SSL のトラブルシューティング

• tet-enforcer プロセスが実行されていることを確認します。ps -ef | grep tet-enforcer

フローエクスポート

Pcap オープン

Secure Workload エージェントが Pcap デバイスをオープンしてフローをキャプチャできない場合、エージェントログにエラーが表示されます。Pcap デバイスが正常に開かれた場合は、次のように報告されます。

I0609 15:25:52.354 24248 Started capture thread for device <device_name>
I0609 15:25:52.354 71912 Opening device {<device_id>}

I0610 03:24:22.354 16614 Opening device <device_name>
[2020/06/10 03:24:23:3524] NOTICE: lws_client_connect_2: <device_id>: address 172.29.
˓→136.139

HTTPS 接続

エージェントとクラスタ間の接続は外部でブロックされているため、フローやその他のシステム情報が配信されません。これはホスト上のネットワーク ファイアウォール、SSL 復号化サービス、またはサードパーティのセキュリティエージェントに関する 1 つ以上の設定の問題が原因で発生します。

• エージェントとクラスタの間に既知のファイアウォールまたは SSL 復号化セキュリティデバイスがある場合は、すべての Secure Workload コレクタと VIP の IP アドレスへの通信が許可されていることを確認してください。オンプレミスクラスタの場合、コレクタのリストは、Secure Workload Web インターフェイスの左側にあるナビゲーションバーの、[トラブルシューティング（Troubleshoot）] > [仮想マシン（Virtual Machines）] の下に表示されます。collectorDatamover-* を参照してください。Secure Workload クラウドの場合、許可する必要があるすべての IP アドレスがポータルにリストされます。

• SSL 復号化があるかどうかを判断するために、openssl s_client を使用して接続を確立し、返された証明書を表示できます。チェーンに証明書が追加されると、エージェントのローカル CA によって拒否されます。SSL のトラブルシューティング

  （注）	通常、「フローエクスポート異常ステータス」を更新するサービスは 5 分ごとに実行されます。この期間は、エージェントのステータス更新が 5000 の小さなバッチで実行されているため、異なる場合があります。そのため、クラスタのエージェントが少ないほど、更新は速くなります。エージェントの数が多い場合、更新には最大 70 分かかることがあります。 データベースに含まれるエージェントレコードの最初のソート後、クラスタとエージェントが安定し、最終的に更新間隔が短くなり、一貫性が向上します。

Windows 証明書の問題

MSI インストーラの証明書の問題

MSI インストーラは、コード署名証明書を使用して署名されています。

MSI インストーラの場合、バージョン 3.6.x 以降および 3.5.1.31 以降

• リーフ証明書：Cisco Systems, Inc

• 中間証明書：DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1

• ルート証明書：DigiCert Trusted Root G4

MSI インストーラの場合、以前のバージョン

• リーフ証明書：Cisco Systems, Inc

• 中間証明書：Symantec Class 3 SHA256 Code Signing CA

• ルート証明書：VeriSign Class 3 Public Primary Certification Authority - G5

タイムスタンプ証明書を使用します。

MSI インストーラの場合、バージョン 3.6.x 以降および 3.5.1.31 以降

• リーフ証明書：Symantec SHA256 TimeStamping Signer - G3

• 中間証明書：Symantec SHA256 TimeStamping CA

• ルート証明書：VeriSign Universal Root Certification Authority

MSI インストーラの場合、以前のバージョン

• リーフ証明書：Symantec SHA256 Timestamping Signer - G2

• 中間証明書：Symantec SHA256 Timestamping CA

• ルート証明書：VeriSign Universal Root Certification Authority

MSI インストーラのデジタル署名が無効な場合、Windows Sensor のインストールまたはアップグレードは失敗します。次の場合、デジタル署名は無効です。

• MSI インストーラの署名ルート証明書または MSI インストーラのタイムスタンプルート証明書が「信頼されたルート証明機関」ストアにない

• MSI インストーラの署名ルート証明書または MSI インストーラのタイムスタンプルート証明書が期限切れまたは失効している

Windows 2012、Windows 2012 R2、Windows 8、Windows 8.1 が該当します

問題 1

CheckServiceStatus : Exception System.InvalidOperationException: Service npcap was not found on computer 
‘.’. —> System.ComponentModel.Win32Exception: The specified service does not exist as an installed service

対処法

• コマンドプロンプトからコマンド certmgr を実行します。

• [信頼できるルート認証局（Trusted Root Certification Authority）] ストアの [DigiCert High Assurance EV Root CA] を選択します。

• 証明書が見つからない場合は、他のマシンからインポートします。

証明書をインストールするには、次の手順を実行します。

稼働中のいずれかのサーバーから証明書「DigiCert High Assurance EV Root CA」を最初にエクスポートします。以下の手順に従います。

• コマンドプロンプトからコマンド certmgr を実行します。

• [信頼できるルート証明局（Trusted Root Certification Authorities）] の下にある [DigiCert High Assurance EV Root CA] 証明書を右クリックします。

• エクスポートされた証明書を非稼働中のサーバーにコピーしてから、証明書をインポートします。

証明書をインストールするには、次の手順を実行します。

• コマンドプロンプトからコマンド certmgr を実行します。

• [信頼できるルート認証局（Trusted Root Certification Authorities）] の下にある [証明書（certificates）] タブを右クリックし、[すべてのタスクのインポート（All tasksImport）] に移動します。

• コピーしたルート証明書を選択し、ストアに追加します。

Windows 2008 R2 に適用

問題 1

CheckServiceStatus : Exception System.InvalidOperationException: Service npcap was not found on
computer ‘.’. —> System.ComponentModel.Win32Exception: The specified service does not exist as an
installed service

解像度

• コマンドプロンプトからコマンド certmgr を実行します。

• [信頼できるルート認証局（Trusted Root Certification Authority）] ストアの [DigiCert High Assurance EV Root CA] を選択します。

• 証明書が見つからない場合は、他のマシンからインポートします。

証明書をインストールするには、次の手順を実行します。

稼働中のいずれかのサーバーから証明書「DigiCert High Assurance EV Root CA」を最初にエクスポートします。以下の手順に従います。

• コマンドプロンプトからコマンド certmgr を実行します。

• [信頼できるルート証明局（Trusted Root Certification Authorities）] の下にある [DigiCert High Assurance EV Root CA] 証明書を右クリックします。

• エクスポートされた証明書を非稼働中のサーバーにコピーしてから、証明書をインポートします。

証明書をインストールするには、次の手順を実行します。

• コマンドプロンプトからコマンド certmgr を実行します。

• [信頼できるルート認証局（Trusted Root Certification Authorities）] の下にある [証明書（certificates）] タブを右クリックし、[すべてのタスクのインポート（All tasksImport）] に移動します。

• コピーしたルート証明書を選択し、ストアに追加します。

Windows ホストの名前変更

シナリオ 1：Windows ホストの名前を変更した後、IP アドレスと VRF 情報が表示されない問題を修正する手順：

• TaaS UI から（IP アドレスと VRF 情報が欠落している新しいホスト名を持つ）エントリを削除します。

• Windows ホストから「Cisco Secure Workload エージェント」をアンインストールし、「Cisco Tetration」ディレクトリを削除します（通常、該当するパスは「C:Program FilesCisco Tetration」）。

• Windows ホストに「Cisco Secure Workload エージェント」をインストールします。

上記の手順を実行すると、TaaS UI でエージェントが IP アドレスと VRF 情報を使用して正常に登録されます。

シナリオ 2：計画された Windows ホストの（事前）名前変更の手順：

• Windows ホストから「Cisco Secure Workload エージェント」をアンインストールし、「Cisco Tetration」ディレクトリを削除します（通常、該当するパスは「C:Program FilesCisco Tetration」）。

• Windows ホストの名前を変更して再起動します。

• Windows ホストに「Cisco Agent」をインストールします（新しいホスト名を使用）。Secure Workload

計画されたホストの名前変更に関する上記の手順に従って、エージェントを新しいホスト名で TaaS UI に登録する必要があります。

プラットフォームが現在サポートされているかどうかを確認する

Windows

• コマンド winver.exe を実行します。

• 「サポートされるプラットフォームと要件」に記載されている内容とこのリリースを比較します

Linux

• cat /etc/os-release を実行します。

• 「サポートされるプラットフォームと要件」に記載されている内容とこのリリースを比較します

AIX

• コマンド uname -a を実行します

• 注：メジャーバージョンとマイナーバージョンが逆になっています。

  p7-ops2> # uname -a
  AIX p7-ops2 1 7 00F8AF944C00

• この例では、ホスト名の後の最初の数字がマイナーバージョン、2 番目の数字がメジャーバージョンであるため、AIX バージョン 7.1 になります。「サポートされるプラットフォームと要件」に記載されている内容とこのリリースを比較します

Windows Installer の問題

• C:\Windows\Installer ディレクトリが存在することを確認してください。これはファイルエクスプローラには表示されません。最も簡単な確認方法は、CMD セッションで次を実行する方法です。dir C:\Windows\Installer

• Windows Installer サービスが無効になっていないかどうかを確認します。サービスを手動に設定する必要があります。

• Windows Installer によって他のエラーがレポートされていないかどうかを確認します。[Windowsログ（Windows Logs）] > [アプリケーション（Application）] > [送信元（Source） > [MsiInstaller] で Windows システムイベントログを確認します。

必要な Windows サービス

以下は、無効になっている場合にエージェントのインストール問題に関係するサービスのリストです。優れた可視性と適用エージェントの初期インストール時およびアップグレード時に、これらのサービスが稼働中であることを推奨します。

（注）	アプリケーション体験サービスは、Windows Server 2008、2008R2、2012、2012R2、および Windows 7 のみが対象です。無効にすると、Npcap のインストール中にファイルのロックが発生し、インストールに失敗する可能性があります。

Npcap がアップグレードされない（手動またはエージェント経由）

• プロセスが現在 Npcap ライブラリを使用している場合、Npcap は正常にアンインストールされないことがあります。実行状況を調べるには、次のコマンドを実行します。

  PS C:\Program Files\Npcap> .\NPFInstall.exe -check_dll
  WindowsSensor.exe, Wireshark.exe, dumpcap.exe
  

プロセスが一覧表示される場合は、Npcap アップグレードを続行する前にそれらのプロセスを停止する必要があります。Npcap を使用しているプロセスがない場合、上記のコマンドにより<NULL>のみが表示されます。

Npcap がインストールされない

• システムにインストールされている CA 証明書を確認します：NPCAP インストーラの証明書の問題

• Windows インストーラの問題を確認します：Windows インストーラの問題

• システム上の他のユーザーがネットワーク インターフェイスに変更を加えていないことを確認します。これが原因で COM ロックが発生し、NDIS ドライバのバインドが妨げられている可能性があります。

Npcap が完全にインストールされているかどうかの確認

1. [コントロール パネル（Control Panel）] > [プログラムと機能（Programs and Features）] をチェックして、Npcap がインストールされているアプリケーションとしてリストされているかどうかを確認します。

2. Npcap パケット ドライバが問題の NIC にバインドされていることを確認します（チェックマークが表示されます）。

   

3. ドライバが正しくインストールされているかどうか確認します。

   C:\Windows\system32>pnputil -e | findstr Nmap
   Driver package provider : Nmap Project
   

4. ドライバサービスがインストールされ、実行中であるかどうかを確認します。

   C:\Windows\system32>sc query npcap
   SERVICE_NAME: npcap
            TYPE : 1 KERNEL_DRIVER
            STATE : 4 RUNNING
   

5. レジストリエントリが存在するかどうかを確認します（Npcap がすでに存在することを確認するためにエージェントで使用されます）。

   C:\Windows\system32>reg query HKLM\software\wow6432node\npcap
   HKEY_LOCAL_MACHINE\software\wow6432node\npcap
             AdminOnly REG_DWORD 0x1
             WinPcapCompatible REG_DWORD 0x0
            (Default) REG_SZ C:\Program Files\Npcap

6. インストールされている Npcap プログラムファイルがすべて存在するかどうかを確認します。

   C:\Windows\system32>dir "c:\program files\npcap"
    Directory of c:\program files\npcap
   04/29/2020 02:42 PM <DIR> .
   04/29/2020 02:42 PM <DIR> ..
   01/22/2019 08:16 AM 868 CheckStatus.bat
   11/29/2016 03:43 PM 1,034 DiagReport.bat
   12/04/2018 11:12 PM 8,908 DiagReport.ps1
   01/09/2019 09:22 PM 2,959 FixInstall.bat
   04/29/2020 02:42 PM 134,240 install.log
   01/11/2019 08:52 AM 9,920 LICENSE
   03/14/2019 08:59 PM 10,434 npcap.cat
   03/14/2019 08:57 PM 8,657 npcap.inf
   03/14/2019 09:00 PM 74,040 npcap.sys
   03/14/2019 08:57 PM 2,404 npcap_wfp.inf
   03/14/2019 09:00 PM 270,648 NPFInstall.exe
   04/29/2020 02:42 PM 107,783 NPFInstall.log
   03/14/2019 09:01 PM 175,024 Uninstall.exe
            13 File(s) 806,919 bytes
             2 Dir(s) 264,417,628,160 bytes free

7. .sys ドライバファイルが Windows のドライバフォルダにあるかどうかを確認します。

   C:\Windows\system32>dir "C:\Windows\System32\Drivers\npcap.sys"
   Directory of C:\Windows\System32\Drivers
   03/14/2019 09:00 PM 74,040 npcap.sys
                     1 File(s) 74,040 bytes
   

NPCAP のインストールまたはアップグレードの実行中のネットワーク接続の問題

Windows 2016 のみに適用

サードパーティの LWF（ライトウェイトフィルタ）ドライバー（netmon など）がある場合、またはセットアップでチーミングアダプタが構成されており、エージェントの展開中に NPCAP がインストールされている場合、次のような状況が発生する可能性があります。

RDP が再接続される

NetBios サービスが再起動する

同様なネットワーク接続に関する問題

これは、Windows 2016 OS のバグが原因です。

Npcap との NIC チーミングの互換性の問題

チーミング NIC 機能は、物理 NIC（Intel、Broadcom、Realtek、MS 仮想アダプタなど）とチーミングドライバ構成 (スイッチベースでロードバランシングまたはフェールオーバーを備え、複数の NIC にパケットを分散するアルゴリズム) を基盤としています。

一部の NPCAP バージョンでは、特に下位のチーミング NIC へのバインド時に、チーミング NIC との互換性の問題があります。

NIC type : Intel(R) 82574L Gigabit Network Connection
Teaming Mode : Switch Independent
Load Balancing Mode: Address Hash
OS : Windows 2012 , Windows 2012 R2, Windows 2016, Windows 2019
NPCAP version: 1.55

（注）	Windows 2008R2 は、Microsoft がサポートする NIC チーミングに対応していません。

ネットワークフローを報告しない VDI インスタンス VM

TetSensor サービスは、NPCAP サービスが実行されているときに、複製された VM のネットワークフローをキャプチャしないことがあります。この問題は、MSI インストーラを使用して [nostart] フラグなしでエージェントがインストールされた場合、または VM テンプレートかゴールデンイメージで PowerShell インストーラを使用し、[goldenImage] フラグなしでエージェントがインストールされた場合に発生することがあります。

この場合、Secure Workload エージェントサービスは VM テンプレートで実行を開始します。NPCAP がインストールされ、VM テンプレートのネットワークスタックにバインドされます。新しい VM が VM テンプレートから複製されると、NPCAP は新しく複製された VM のネットワークスタックに正しくバインドされません。その結果、NPCAP はネットワークフローをキャプチャできません。

Npcap でのネットワークパフォーマンス

Windows TetSensor サービスが実行されていると、ネットワークパフォーマンスが影響を受けることが確認されています。Windows TetSensor サービス（tetsen.exe）は、Npcap を使用してネットワークフローをキャプチャします。ネットワークフローをキャプチャする Npcap の実装と、tetsen.exe へのネットワークフローが、ネットワークパフォーマンスに影響を及ぼします。

TetSensor をインストール後にネットワークパフォーマンスを比較：クライアント：Windows 2016

Npcap 1.55

TetSensor 構成：適用モード WFP を使用した会話モード

サーバー：Windows 2016

Npcap 1.55

TetSensor 構成：適用モード WFP を使用した会話モード

cmd の実行：iperf3.exe -c<server_ip> -t 40

Npcap 0.9990 でのネットワークパフォーマンス

TetSensor をインストール後にネットワークパフォーマンスを比較：クライアント：Windows 2016

Npcap 0.9990

TetSensor 構成：適用モード WFP を使用した会話モード

サーバー：Windows 2016

Npcap 0.9990

TetSensor 構成：適用モード WFP を使用した会話モード

cmd の実行：iperf3.exe -c<server_ip> -t 40。表：Npcap 0.9990 のネットワークパフォーマンス

class longtable

（注）	パフォーマンスは、インストールされている Windows Npcap バージョン、Windows OS、およびネットワーク構成によって異なる場合があります。

OS のパフォーマンスや安定性の問題

インストールされている NPCAP のバージョンや構成が Secure Workload ソフトウェアでサポートされていない場合、OS で未知のパフォーマンス問題や安定性の問題が発生する可能性があります。

サポートされている NPCAP バージョン：0.991 および 1.55

GPO の設定

ポリシーを適用するエージェントでは、ローカル設定または GPO のいずれかを使用してファイアウォールのみを有効にする必要があります。他のすべての GPO 設定は行わず、「未設定」のままにしておく必要があります。

• GPO 設定が適用をブロックしているかどうかを確認するには、 C:\Program Files\Cisco Tetra- tion\Logs\TetEnf.exe.log のログを確認し、次のエラー例がないかを探します。

• 「ルールを保持 = いいえ」の設定でルールの競合が発生:「グループポリシーに設定されれているファイアウォールがあります。Secure Workload エージェントには、これを削除する権限がありません。」

• ファイアウォールがオフに設定されている: 「GPO が DomainProfile のファイアウォールを無効にしています」

• デフォルトアクションが設定されている:「グループポリシーは、DomainProfile のデフォルト受信アクションと競合しています」

• ホストに適用されている GPO ポリシーを確認するには、gpresult.exe /H gpreport.html を実行し、生成された HTML レポートを開きます。以下の例では、「ルールを保持」が「いいえ」に設定されている場合、Secure Workload エージェントのファイアウォールが適用する受信ルールは、適用エージェントと競合します。

クラスタ通信へのエージェント

Secure Workload エージェントは、複数のチャネルを介してクラスタへの接続を維持します。エージェントの種類によって、接続数は異なります。

接続のタイプ

• WSS：クラスタへのポート 443 を介した永続的なソケット接続

• チェックイン：15 ～ 20 分ごとにクラスタへの HTTPS コールを行い、現在の構成を確認し、更新を確認し、クラスタに対してエージェントのアクティブ状態を更新します。これは、アップグレードの失敗も報告します。

• フローエクスポート：フローメタデータをクラスタに送信するための、ポート 443（TaaS）または 5640（オンプレミス）を介した永続的な SSL 接続

• 適用：ポート 443（Taas）または 5660（オンプレミス）を介した永続的な SSL 接続により、適用ポリシーを取り込み、適用状態を報告します。

接続状態の確認

Teration UI は、非アクティブな（チェックインしなくなった）エージェント、（[統計（Stats）] の [エージェントワークロードプロファイル（Agent Workload Profile ）] ページにある）エクスポートされていないフロー、または失敗した適用のいずれかを報告します。エラーに応じてワークロードのさまざまなログを確認し、問題の原因を特定することができます。

非アクティブなエージェント

Windows ログ：C:\Program Files\Cisco Tetration\Logs\TetUpdate.exe.log

Linux ログ：/usr/local/tet/logs/check_conf_update.log

HTTP 応答コード 304 が想定されており、設定の変更がないことを意味します。エラーコード = 2 も同様に想定されます。その他の HTTP 応答コードは、Secure Workload クラスタ上の WSS サービスと通信する際の問題を示します。

Tue 06/09/2020 17:25:25.08 check_conf_update: "curl did not return 200 code, it's 304,
˓→ exiting"
Tue 06/09/2020 17:25:25.08 check_conf_update: "error code after running check_conf_
˓→update = 2"

• [304] 想定されており、設定の変更はありません。チェックインに成功しました

• [401] 登録に失敗しました。アクティベーションキー（TaaS） がありません

• [403] エージェントはすでに同じ UUID でクラスタに登録されています

• [000] SSLでの接続の問題を示します。curl が WSS サーバーに到達できなかったか、証明書に問題があります。SSL トラブルシューティングで、SSL のトラブルシューティングを確認してください。

エクスポートされていないフロー

Windows ログ：C:\Program Files\Cisco Tetration\Logs\TetSen.exe.log

Linux ログ：/usr/local/tet/logs/tet-sensor.log

以下は WSS への接続が成功したことを示します

cfgserver.go:261] config server: StateConnected, wss://<config_server_ip>:443/wss/
˓→<sensor_id>/forensic, proxy:

以下はコレクタへの接続が成功したことを示します

collector.go:258] next collector: StateConnected, ssl://<collector_ip>>:5640

WSS またはコレクタへの接続中にエラーが発生した場合は、ファイアウォールの設定を確認するか、エージェントと Secure Workload の間で SSL 復号化が行われていないかどうかを確認してください。SSL のトラブルシューティング を参照してください。

ポリシー適用の失敗

Windows ログ：C:\Program Files\Cisco Tetration\Logs\TetEnf.exe.log

Linux ログ：/usr/local/tet/logs/tet-enforcer.log

ssl_client.cpp:341] Successfully connected to EFE server

EFE サーバーへの接続中にエラーが発生した場合は、ファイアウォールの設定を確認するか、エージェントと Secure Workload の間で SSL 復号化が行われていないかどうかを確認してください。SSL のトラブルシューティング を参照してください。

エージェント通信の概要

Secure Workload エージェントは、TLS を使用して Secure Workload Cloud SaaS サーバーへの TCP 接続を保護します。これらの接続は、次の 3 つの特徴的なチャネルに分類されます。

• エージェント -> ポート TCP/443（TLS）（sensorVIP）経由の Cisco Secure Workload SaaS 制御チャネル

  これは、エージェントが Secure Workload に登録できるようにする低ボリュームの制御チャネルであり、設定のプッシュとソフトウェアアップグレード通知も処理します。

• エージェント -> TCP/443（TLS）（コレクタ）経由の Cisco Secure Workload SaaS フローデータ

  フローデータは、抽出されたフローメタデータ情報であり、このデータは一度に 16 個の IP アドレスのセット 1 つに送信されます。2 番目の IP アドレスのセットはスタンバイ用です。これは、実際のサーバートラフィックの約 1 ～ 5% を占めます。

• エージェント -> TCP/443（TLS）（efe）を介した Cisco Secure Workload SaaS 適用データ

  適用データチャネルは、ポリシーをセンサーにプッシュし、適用統計を収集するために使用される低ボリュームの制御チャネルです。

センサーは、エージェントとともにインストールされているローカル CA に対して、Secure Workload クラウドの制御、データ、および適用サーバーからの TLS 証明書を検証します。他の CA は使用されないため、エージェントに送信される他の証明書は検証に失敗し、エージェントは接続されません。結果的に、エージェントは登録、チェックイン、フローの送信、または適用ポリシーの受信を行わなくなります。

エージェント通信の IP トラフィックの構成

多くの場合に使用される一般的な構成は、エージェント（ワークフロー）と Secure Workload SaaS の間に境界ファイアウォールと、場合によってはプロキシを配置することです。

各顧客（テナント）は、特定の SaaS クラスタに割り当てられます。そのクラスタの IP アドレスは、[管理（Manage）] > [サービス設定（Service Settings）] > [IPアドレス（IP Addresses）] > [サービスIP（Service IPs）]で確認できます。.

ファイアウォールまたはプロキシを設定する際は、次の IP を許可する必要があります。

• TLS/HTTPS を介したアウトバウンドポート 443 を許可します。

• 復号プロキシが使用されている場合は、それらの IP のプロキシバイパスと SSL/TLS バイパスを設定します。

• 透過的なプロキシが使用されている場合は、特定の SaaS IP アドレスをルーティングし、バイパスルールを設定する必要があります。エージェントは自動 HTTPS リダイレクトを実行できません。

（注）	アウトバウンド ファイアウォール ルールで、宛先メタデータコレクタ IP へのトラフィックフローが許可されていることを確認します。

（注）	ユーザーインターフェイスでアウトバウンドゲートウェイの IP アドレスを編集できるようになりました。この機能により、ワークロードから発信されるメタデータトラフィックの宛先への許可が可能になります。

多くの場合に使用される一般的な構成は、エージェント（ワークフロー）と Secure Workload TaaS の間に境界ファイアウォールと、場合によってはプロキシを配置することです。

（注）	Secure Workload は、オンボーディング中にもゲートウェイ/NAT IP 情報を収集し、テナント作成時に情報を自動的に追加します。ポータルで新しい IP アドレスを追加するか IP アドレスを変更する場合、変更には Secure Workload スタッフによる確認と承認が必要です。

TaaS ポータルでゲートウェイ/NAT IP アドレスを追加することに加えて、アウトバウンドトラフィックと変更されていないトラフィックを許可するために、ネットワークにさらに変更が必要になる場合があります。

• 境界ファイアウォールで TLS/HTTPS を介したアウトバウンドポート 443 を許可します。

• 復号 Web プロキシが使用されている場合は、Web プロキシでプロキシバイパスと SSL/TLS バイパスを構成します。

• データセンターで透過的な Web プロキシを使用している場合は、特定の SaaS IP アドレスをルーティングし、バイパスルールを構成する必要があります。センサーは、自動 HTTPS リダイレクトを実行できない接続です。

エージェントの通信先 IP のリストは、TaaS ポータルで入手できます。ファイアウォールのアウトバウンド構成とプロキシバイパスに追加する IP には、collector-n、efe-n（適用が展開されている場合のみ）、および sensorVIP というラベルが付けられます。通常、エージェント通信用に追加する IP は 17 ～ 33 個ありますが、TaaS 構成によってはそれ以上または以下になる可能性があります。

SSL/TLS 接続のトラブルシューティング

前のセクションで説明したとおり、エージェント通信の SSL/TLS 復号化をバイパスするために、明示的または透過的な Web プロキシを設定することが重要です。バイパスが設定されていない場合、これらのプロキシは復号化を試みる可能性があります

SSL/TLS トラフィックは、自身の証明書をエージェントに送信することによるトラフィックです。エージェントはローカル CA のみを使用して証明書を検証するため、これらのプロキシ証明書によって接続エラーが発生します。

症状には、エージェントがクラスタに登録できない、エージェントがチェックインしない、エージェントがフローを送信しない、（適用が有効になっている場合）エージェントが設定の適用を受信しないなどがあります。

（注）	以下のトラブルシューティング手順は、デフォルトのインストールパスが使用されたことを前提としています。Windows: C:Program FilesCisco Tetration Linux: /usr/local/tet. エージェントを別の場所にインストールした場合は、手順をその場所に置き換えてください。

SSL/TLS 接続の問題は、エージェントログで報告されます。ログに SSL エラーがあるかどうかを確認するには、観察された関連する問題に対して次のコマンドを実行します。

登録、チェックイン

Linux

grep "NSS error" /usr/local/tet/log/check_conf_update.log

Windows（PowerShell）

get-content "C:\Program Files\Cisco Tetration\logs\TetUpdate.exe.log" | select-
˓→string -pattern "curl failed SSL peer certificate"

フロー

報告される SSL/TLS 接続問題のほとんどは、エージェントの最初の接続および登録中に発生します。フローを送信するには、接続を試みる前に登録が完了している必要があります。ここで表示される SSL/TLS エラーは、センサーの VIP IP は許可されているが、コレクタの IP が許可されていないことが原因です。

Linux

grep "SSL connect error" /usr/local/tet/log/tet-sensor.log

Windows（PowerShell）

get-content "C:\Program Files\Cisco Tetration\logs\WindowsSensor*.log" | select-
˓→string -pattern "Certificate verification error"

施行

Linux

grep "Unable to validate the signing cert" /usr/local/tet/log/tet-enforcer.log

Windows（PowerShell）

get-content "C:\Program Files\Cisco Tetration\logs\WindowsSensor*.log" | select-
˓→string -pattern "Handshake failed"

上記のログチェックに SSL エラーが表示された場合は、次のコマンドを使用して、エージェントに送信されている証明書を確認できます。

Explicit Proxy - where a proxy is configured in user.cfg

Linux

curl -v -x http://<proxy_address>:<port> https://<sensorVIP>:443

Windows（PowerShell）

cd "C:\Program Files\Cisco Tetration"
.\curl.exe -kv -x http://<proxy_address>:<port> https://<sensorVIP>:443

透過型プロキシ：user.cfg プロキシ設定は不要です。このプロキシは、エージェントからインターネットへのすべての HTTP（S）トラフィック間で設定されたプロキシです。

Linux

openssl s_client -connect <sensorVIP from TaaS Portal>:443 -CAfile /usr/local/tet/
˓→cert/ca.cert

Windows（PowerShell）

cd C:\Program Files\Cisco Tetration
.\openssl.exe s_client -connect <sensorVIP from TaaS Portal>:443 -CAfile cert\ca.cert

openssl s_client respose で次のものを探しています

Verify return code: 0 (ok)

エラーが表示された場合は、証明書を調べてください。証明書（チェーン）の例には、次の証明書のみを含める必要があります（CN IP は一例です）。

証明書チェーン

0 s:/C=US/ST=CA/L=San Jose/O=Cisco Systems, Inc./OU=Tetration, Insieme BU/CN=129.146.
˓→155.109
i:/C=US/ST=CA/L=San Jose/O=Cisco Systems, Inc./OU=Tetration Analytics/CN=Customer CA

追加の証明書が表示される場合は、エージェントと Cisco Secure Workload の間に Web 復号化プロキシがある可能性があります。セキュリティグループまたはネットワークグループに連絡し、「エージェント通信の IP トラフィックの構成」セクションにリストされている IP を使用して、プロキシバイパスが設定されていることを確認してください。

Windows 2016 サーバーで Windows Sensor のインストールスクリプトが失敗する：「基になる接続が切断されました。受信時に予期しないエラーが発生しました」というエラーメッセージが表示される場合があります。考えられる理由は、PowerShell で設定されている SSL/TLS バージョンである可能性があります。

実行されている SSL/TLS バージョンを調べるには、次のコマンドを実行します。

[Net.ServicePointManager]::SecurityProtocol

上記のコマンドの出力が次である場合：

Ssl3, Tls

次に、以下のコマンドを使用して許可されたプロトコルを変更し、インストールを再試行します。

[Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Ssl3,
˓→Tls,Tls11,Tls12'

エージェントの操作

Q：エージェントを正常にインストールしましたが、[UIセンサーモニタリング（UI Sensor Monitoring）] ページに表示されません。

A：エージェントが動作を開始する前に、クラスタ内で実行されているバックエンドサーバーにエージェントを登録する必要があります。エージェントが UI ページに表示されない場合は、登録に失敗したことが原因であると考えられます。いくつかのポイントをチェックすることで、登録に失敗した理由を確認できます。

• エージェントとバックエンドサーバー間の接続が正しく機能しているかどうかを確認します。

• curl リクエストをバックエンドサーバーに正しく送信できるかどうかを確認します。

• HAProxy アクセスとバックエンドサーバーのログをチェックして、登録リクエストがサーバーに届いたかどうかを確認します。

• ログファイルで curl リクエストから返されたエラーを確認します。

Q：エージェントがインストールされ、UI ページでエージェントを確認できましたが、[ソフトウェアバージョン（SW Ver）] 列に、バージョンを示す文字列ではなく [初期化中（initializing）] と表示されます。

A：エージェントを最初にインストールしてバックエンドサーバーに登録した後、エージェントがバージョンを報告するようになるまでさらに 30 分かかります。

Q：エージェントは適切にアップグレードされていますが、[ソフトウェアバージョン（SW Ver）] フィールドには長時間にわたり（数時間など）古いバージョンが表示されたままになっています。

A：エージェントが正常にアップグレードされると、エージェントは curl リクエストを送信して現在実行中のバージョンを報告し、同じリクエストで新しいバージョンがあるか確認しようとします。次のようないくつかの理由により、リクエストがバックエンドに到達できなかった可能性があります。

• リクエストがタイムアウトし、時間内に応答を取得できませんでした。

• ネットワークに問題が発生し、エージェントがバックエンドサーバーに接続できませんでした。

Q：RHEL/CentOS-6.x でエージェントを実行し、正常に動作しています。OS を RHEL/CentOS-7.x にアップグレードする予定です。アップグレード後もエージェントは動作しますか？

A：現在、OS をアップグレードするシナリオ（特にメジャーリリースのアップグレード）はサポートされていません。OS のアップグレード後にエージェントを動作させるには、次の手順を実行します。

• 既存のエージェントソフトウェアをアンインストールします。

• 証明書を含むすべてのファイルをクリーンアップします。

• UI に移動し、エージェントエントリを削除します。

• OS を目的のバージョンにアップグレードします。

• 新しい OS にエージェントソフトウェアをインストールします。

Q：RHEL/CentOS-6.x でエージェントを実行し、正常に動作しています。ホストの名前を変更する予定です。名前の変更/再起動後もエージェントは動作しますか？

A：エージェント ID は、ホスト名と bios-uuid を含むホストの一意性に基づいて計算されます。ホスト名を変更すると、ホストの ID が変更されます。次の操作を実行することをお勧めします。

• 既存のエージェントソフトウェアをアンインストールします。

• 証明書を含むすべてのファイルをクリーンアップします。

• UI に移動し、古いエージェントエントリを削除します。

• Windows ホストの名前を変更して再起動します。

• エージェントソフトウェアを再インストールします。

Q：Windows ホストで、ルールの追加/削除/変更によってファイアウォールの逸脱が発生しました。ルールを探すにはどうすればよいですか？

A：逸脱が検出されると、エージェントはファイアウォールイベントの最後の 15 秒間を「C:\Windows\System32\config\systemprofile\AppData\Roaming\tet\firewall_events」に記録します。逸脱の原因となったルールは、policy_dev_<policy id>_<timestamp>.txt として作成された最後のファイルで見つかります。

Q：Windows ホストにエージェントを正常にインストールしましたが、センサーからのフローの報告が表示されません。なぜですか？

A：Windows ホストでフローを収集するには、Npcap が必要です。Npcap は、エージェントが正常にインストールされてから 10 秒後にインストールされます。数分経ってもセンサーからフローが報告されない場合は、エージェントとバックエンドサーバーが接続されているか、および「Npcap の問題」を参照し、Npcap が正しくインストールされているか確認してください。

Q：Windows ホスト（2008 R2）にエージェントを正常にインストールしましたが、tetsensor サービスの実行中にシステムクロックがドリフトします。なぜですか？

A：これは、Go および Windows 2008 R2 の既知の問題です。詳細については、「Golang and Win2008 R2」を参照してください。

tetsensor サービスの一部として実行されるプロセス tet-main.exe は、Go バージョン 1.15 を使用して構築されています。そのため、tetsensor サービスの実行中にシステムクロックがドリフトします。

この問題は、Windows 2008 R2 ワークロードが外部 NTP サーバーまたはドメインコントローラを NTP サーバーとして使用するように設定されている場合に発生します。

考えられる回避策：

1. NTP に定期的にクロックを同期させます：w32tm /resync /force

2. tet-main.exe を手動で無効にします。

   • 「管理者」権限で cmd.exe を実行します。

   • regedit.exe を実行します。

   • 「HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\TetSensor」に移動します。

   • 「ImagePath」をダブルクリックします。

   • 値を編集し、tet-main.exe を削除します。

     ビフォー：“C:\Program Files\Cisco Tetration\TetSenEngine.exe” TetSensor TetSen.exe “-f sensor_config” tet-main.exe ” ” TetUpdate.exe

     アフター：“C:\Program Files\Cisco Tetration\TetSenEngine.exe” TetSensor TetSen.exe “-f sensor_config” TetUpdate.exe

   • tetsensor サービスを再起動します。

     （注）	エージェントがアップグレードされるたびに、tet-main.exe を無効にしてください。

3. 外部 NTP サーバー設定を削除します。

   • コマンドを実行します：w32tm /config /update /manualpeerlist: /syncfromflags:manual /reliable:yes

   • Windows タイムサービス、W32Time を再起動します。

エージェント トラブルシューティング ツール

エージェント トラブルシューティング ツールを使用すると、Windows 環境でエージェントに関する一般的な問題をトラブルシュートできます。このツールは、エージェントのさまざまな側面をトラブルシュートできる、複数のパラメータを持つ PowerShell スクリプトです。次の PowerShell パラメータを使用して、エージェントのさまざまな側面をトラブルシュートできます。

• -agentHealth：このオプションは、エージェントの正常性を確認し、対処する必要がある問題を報告します。

• -agentRegistration：このオプションを使用すると、エージェント登録に関する既知の問題を確認できます。

• -agentUpgrade：このオプションを使用すると、エージェントのアップグレードに関する既知の問題を確認できます。

• -enforcementHealth：このオプションは、適用の全体的な正常性を確認し、最新のポリシーがプログラムされている状態を確保します。

• -collectLogs：このオプションは、デバッグログを収集します。このログは、さらなるトラブルシューティングのために分析できます。

エージェント トラブルシューティング ツール スクリプトを実行するには、次の手順を実行します。

1. 管理者として Windows（PowerShell）を開きます。

2. CSW のインストールディレクトリ（このディレクトリの場所は、デフォルトでは「C:\Program Files\Cisco Tetration」）に移動します。

3. 次のコマンドを使用してスクリプトを実行します。

   .\AgentTroubleshooting.ps1 たとえば、エージェントの正常性を確認するには、-agentHealth パラメータを指定してスクリプトを実行します。.\AgentTroubleshooting.ps1 -agentHealth