Here’s how to troubleshoot the issue:

問題が解決しない場合は、 Netskopeサポートにご連絡ください。

Cloud Exchangeコンテナの状態を確認する必要があります。 次のコマンドを使用してステータスを確認します。

For Ubuntu/CentOS:
sudo Docker ps

RHELの場合：
sudo podman-compose ps

コンテナーが実行されていない場合は、次のコマンドを使用してコンテナーを停止します。
./start

RHELをご利用の場合は、SELinuxが無効になっていることを確認してください。Cloud Cloud Exchange SELinux上で公式にテストされていません。 SELinuxを無効にすることをお勧めします。

次のコマンドを使用して、ipv4 forwarder status のステータスも確認します。
systemctl net.ipv4.ip_forward

このコマンドの値が1の場合、それは有効になっていることを意味します。しかし、値が0の場合は、以下のコマンドを実行して有効にする必要があります。
systemctl net.ipv4.ip_forward=1

コンテナの状態を確認するには、 ta_cloud_exchangeフォルダに移動する必要があります。

コンテナが稼働している場合は、ホストマシンのネットワーク接続を確認する必要があります。接続状況を確認するには、次のコマンドを実行してください。 以下のコマンドで接続状況を確認できます。
curl -v <IP of Local Host>:443 [i.e curl -v 127.0.0.1:443]
curl -v www.github.com:443

接続が正常に機能している場合は、CEを再起動して確認してください。次のコマンドを使用して CE を再起動します。
./stop
./start

また、SSL証明書の有効期限が切れている可能性もあります。もしあなたが 企業SSL証明書をお持ちの場合は、証明書を検証してください。 デフォルトのCloud Exchange SSL 証明書を使用している場合、証明書の有効期間は 1 年間です。 それも確認してください。

証明書の有効期限が切れている場合は、この文書に記載されている手順に従ってください。

今VMを再起動しています。

シナリオ: CE の古いバージョンでは、プラグインのインポートに関連するエラーが継続的に表示されることがあります。

影響：CE自体は正常に機能していますが、CE監査ログにインポートエラーが継続的に記録されています。

解決策：このエラーは機能的な影響を及ぼさないため、無視しても問題ありません。

Issue Description

プラグインを保存しようとすると、次のエラーが発生します。

Error: Value error, Validation error occurred. No AWS Credentials were found in the environment. Deploy the
plugin into AWS environment or use AWS IAM Roles Anywhere authentication method.

このエラーが発生した場合、主な原因は、AWS EC2インスタンスのメタデータで設定されている「HTTP PUTレスポンスの期待値制限」に関連している可能性が高いです。これは、インスタンスメタデータサービスへのHTTPリクエストがネットワーク内で破棄されるまでにどれだけの距離を移動できるかを決定します。

What to Do

この問題を解決するには、EC2インスタンスの「HTTP PUTレスポンスホップ制限」を増やす必要があります。ご希望に応じて、以下のいずれかのオプションを選択して設定を更新してください。

Option 1 : AWSコンソール経由でメタデータ設定を更新する

1. AWS コンソールで EC2 インスタンスに移動します < EC2 インスタンスSelect < アクション < インスタンスメタデータオプションの変更。

2. 「インスタンスメタデータオプションの変更」をクリックすると、以下のような画面が表示されます。

3. デフォルトのホップ制限は1に設定されている可能性が高いです。これは、メタデータ応答が送信元のインスタンスにのみ送信され、それ以上先にルーティングされないことを意味します。「HTTP PUT応答の期待値制限」の値を3に更新し、設定を保存します。

4. 完了したら、 Cloud Exchangeに移動して試してプラグインを保存します。 これにより、プラグインの設定が正常に完了するはずです。

Option 2 : AWS CloudShellを使う(コマンドライン)

コマンドラインインターフェース（CLI）をご希望の場合、またはコンソールにオプションが表示されない場合は、次の手順に従ってください。

1. AWS CloudShellを開きます。

2. 現在のホップ制限を確認します（ i-xxxxxxxxxxxxxxxxx EC2インスタンスIDに置き換えてください）。

aws ec2 describe-instances --instance-ids i-xxxxxxxxxxxxxxxxx --query
'Reservations[].Instances[].MetadataOptions'

3. Verify the current value of the http-put-response-hop-limit parameter.

4. ホップ制限を3に更新します（ i-xxxxxxxxxxxxxxxxx EC2インスタンスIDに置き換えてください）。

aws ec2 modify-instance-metadata-options \
2 --instance-id i-xxxxxxxxxxxxxxxxx \
3 --http-put-response-hop-limit 3

5. 以下のコマンドで変更を確認します。

aws ec2 describe-instances --instance-ids i-xxxxxxxxxxxxxxxxx --query
'Reservations[].Instances[].MetadataOptions'

6.完了したら、 Cloud Exchangeに移動して試すと、プラグインを保存できます。 これにより、プラグインの設定が正常に完了するはずです。

RabbitMQコンテナの状態がダウンと表示されています。トラブルシューティングを行うには、CE UI を開き、各ノードの RabbitMQ コンテナのコンテナ状態を確認します。RabbitMQ コンテナの状態が大多数のノードでダウンしている場合は、次の手順を実行してください。 

1. RabbitMQ管理UIを次のURLで開きます。

http://<CE_UI_IP>:15672/

ユーザー名: user パスワード: CEのメンテナンスパスワードこれらのエラー「Network partition Detected.mnesia」が観測された場合、この RabbitMQ クラスターでネットワークパーティションが発生しました。Steps to Resolve Network partition issue 1.stop スクリプトを使用してコンテナを 1 つずつ停止します。

$ sudo ./stop

2. CE ノードを 1 つずつ再度開始します (最初にプライマリ ノードで開始スクリプトを実行します):-

$ sudo ./start

3. CE HomeダッシュボードとRabbitMQダッシュボードも監視してください。注: キュー内の取り込み/共有タスクは、CE によってまだ実行されていないため、CE 内に存在していても失われます。

シナリオ: 既存のクラスタを変更していて、停止スクリプトで停止した後、開始スクリプトで開始した後にクラスタリングの問題が発生した場合、特にノードの追加/削除または移行中に、この問題が発生する可能性があります。

解決策：以下のメッセージが表示される場合、インスタンス2をクラスターから削除する際に何らかの問題が発生したことを意味します。「ノード 'rabbit@instance1' はノード 'rabbit@instance2' とクラスタリングされていると考えているが、'rabbit@instance2' はそうは考えていない」

1. instance2 .
   で停止スクリプトを実行します。$ sudo ./stop
2. instance1に移動して、以下のコマンドを実行してください。（必ずinstance1を実際のIPアドレスまたはホスト名に置き換えてください。）docker を実行している場合は、次のコマンドを使用します:
   $ docker-compose -f docker-compose-ha.yml exec -- rabbitmq-stats rabbitmqctl forget_cluster_node rabbit@instance2
   podman の場合、次のコマンドを使用します:
   $ podman-compose -f podman-compose-ha.yml exec -- rabbitmq-stats rabbitmqctl forget_cluster_node rabbit@instance2
3. 次に、 instance2で開始スクリプトを実行します。
   $ sudo ./start

シナリオ: セットアップ スクリプトの実行中に、CE と互換性のないシステム仕様が原因で、次のエラーが表示される場合があります。「CE サイジング プロファイル チェック: ラージ プロファイルで失敗しました」または「CE サイジング プロファイル チェック: ミディアム プロファイルで失敗しました」。

影響：最低システム要件を満たすまで、CEの設定はできません。

解決：

• お使いのマシンに正確に8個または16個のCPUが搭載されていることを確認してください。これにより、それぞれ中規模または大規模のプロファイルが決定されます。
  マシンがオンプレミスのインフラストラクチャにデプロイされている場合は、要件に応じてCPU数をプロファイルに合わせて更新してください。マシンがクラウドインフラストラクチャ（AWS、Azureなど）にデプロイされている場合は、新しいインスタンスを作成する必要があります。
• ミドルプロファイルの場合、最小RAM容量は16GB、総ディスク容量は80GBです。
• 大規模プロファイルの場合、最小RAM容量は32GB、総ディスク容量は120GBです。
• 両方のプロファイルには、最低20GBの空きディスク容量が必要です。

ブラウザからCloud Exchange UIがフリーズまたはアクセス不能に遭遇する場合、これはDocker/Podman環境での設定要件に関連している可能性があります。Dockerは特にnet.ipv4.ip_forwardを必要とします発信接続を有効にする設定（ https://github.com/moby/moby/issues/490 ）。Docker ではユーザーがこの設定を手動で有効にすることを想定していますが、Podman では異なる方法で処理されることに注意してください。詳細はhttps://github.com/containers/podman/issues/399 を参照してください。

Cloud Exchangeのインストール、移行、またはアップグレード中にエラーが発生した場合は、弊社がサポートいたします。サポートを受けるには、以下の手順に従ってください。

1. サポートチケットの発行：Cloud Exchangeのインストール、移行、またはアップグレード中にエラーが発生した場合は、Netskopeサポートにサポートチケットを発行してください。弊社のエンジニアチームが迅速に問題解決をサポートいたします。
2. 関連情報の提供：サポートチケットを開く際は、以下の詳細情報を必ず含めてください。
   • プラットフォームログ: Cloud Exchange > Logging > Export Logsにアクセスすることでプラットフォームログをエクスポートできます。
   • 診断ログ：診断ログの収集方法については、こちらのドキュメントを参照してください。

その他のリソース：

Cloud Exchangeの様々な側面に関する詳細なドキュメントについては、以下のリンクを参照してください。

• インストール方法：インストール手順書
• アップグレードと移行について：最新バージョンへのアップグレードに関するドキュメント
• 高可用性デプロイメントの場合：高可用性デプロイメントに関するドキュメント

私たちは、Cloud Exchangeをスムーズにご利用いただけるよう尽力しており、あらゆる段階でお客様をサポートいたします。

エラーメッセージは以下のとおりです。

Network netskope-cloud-threat-exchange-docker-compose_default Error 0.0s failed to create network netskope-cloud-threat-exchange-docker-compose_default: Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network.

この問題は、当該機器のネットワークに特有のものです。Dockerネットワークがホストネットワークと競合しているため、Dockerネットワークが正常に作成されません。Dockerのネットワーク設定を変更するには、次のドキュメントを参照してください： https://docs.docker.com/compose/compose-file/06-networks/

Possible Root Cause

• コアコンテナが再起動していました。次のコマンドを使用して、コア コンテナのステータスを確認します。
  

  docker ps [Ubuntu]
  podman-compose ps [RHEL]

1. まず、doreコンテナのログを確認してください。
   

   docker compose logs -f core [Ubuntu]
   podman-compose logs -f core [RHEL]

   以下のエラーが表示された場合、CoreコンテナがRabbitMQコンテナに接続できていないことを示しています。
   

   PLAIN login refused: user 'user'

   まず、このコマンドを使用して RabbitMQ データを削除できます。
   Cloud Exchangeフォルダに移動してください。
   

   rm -rf data/rabbitmq/data/rabbit@rabbitmq-stats*

   しかし、これは現在のキューのデータを損失する結果となる。もう1つの手順は、RabbitMQユーザーを再作成することです。RabbitMQコンテナにログインしてください。
   

   docker exec -ti <Container ID> sh
   podman exec -ti <Container ID> sh

• List Users
  

  rabbitmqctl list_users	

  既存ユーザーを削除する
  

  rabbitmqctl delete_user user

  これにより、新しいユーザー名とパスワードが追加されます。
  

  rabbitmqctl add_user user <MAINTENENCE_PASSWORD>

  これにより、ユーザーは管理者権限を取得します。
  

  rabbitmqctl set_user_tags user administrator

  これはユーザーの権限を設定します。
  

  rabbitmqctl set_permissions -p / user "." "." ".

考えられる原因は3つあります。

1. Mongo データ ディレクトリのアクセス許可の問題。
2. Core/Mongo-DBコンテナがダウンしています。
3. CEメンテナンスパスワードが間違っています。

1.Mongo データ ディレクトリのアクセス許可の問題について

Verify

docker-compose.yml を含むディレクトリ内でls -lRn .実行します。

mongo-data ディレクトリは、UID 1001 のユーザーが読む/書き込みアクセスできる必要があります。

./data/mongo-data:
total 0
drwxr-xr-x. 3 1001 0 16 Apr 14 18:16 data

Solution mongo データ ディレクトリへのアクセス許可の問題:

セットアップスクリプトを再度実行してください./setupファイル権限を修正します。

CEを再起動してください。

2. core/mongo-dbコンテナがダウンしている問題について

Verify

コンテナの状態を確認してくださいsudo docker-compose ps 、すべてのコンテナが稼働中である必要があります。

$ sudo docker-compose ps
Name Command
State Ports
---------------------------------------------------------------------------------------------------------------- 
ce_330_core_1 /bin/sh start.sh Up 80/tcp
ce_330_mongodb-primary_1 /opt/bitnami/scripts/mongo ... Up 0.0.0.0:27018->27017/tcp ce_330_rabbitmq-stats_1 /opt/bitnami/scripts/rabbi ... Up 15671/tcp, 0.0.0.0:15672->15672/tcp, 25672 /tcp, 4369/tcp, 5551/tcp, 5552/tcp, 5671/tcp, 0.0.0.0:5672->5672/tcp
ce_330_ui_1 /bin/sh start.sh Up 0.0.0.0:443->3000/tcp, 80/tcp ce_330_watchtower_1 /watchtower --http-api-update Up 0.0.0.0:8080->8080/tcp

Solution core/mongo-dbコンテナがダウンしています。

コンテナがダウンしている場合は、以下の手順に従ってください。

sudo docker-compose down
sudo ./start

3. メンテナンスパスワードが間違っているという問題

Verify

コアログを確認してください `sudo docker-compose logs core` で「認証エラー」がないか確認してください。

顧客が CE バージョン 3.2.0 または 3.2.0 未満で、同じ MongoDB を使用しているか確認してください。

Solution メンテナンスパスワードが間違っています。

以下の手順を実行してください。

sudo docker-compose down
sudo rm -rf .env
sudo ./setup
Add maintenance password as "cteadmin"
sudo ./start

セットアップ時にメンテナンスパスワードに特殊文字が使用された可能性があります。 RabbitMQはこれをサポートしておらず、コンテナ間の通信がRabbitMQと連携しないため、タスクのスケジュールを試みる他のサービスに問題が発生します。

メンテナンスパスワードを再設定するには、docker-compose.yml が存在するディレクトリから以下のコマンドを実行してください。

sudo docker-compose down
sudo rm -rf .env
sudo ./setup
Add maintenance password.
sudo ./start

この問題は、Podmanに再起動後にコンテナを自動的に再起動する機能が含まれていないために発生します。この動作は、Podmanが一般的に使用されているRHEL（Red Hat Enterprise Linux）サーバーのユーザーにとって特に重要です。 。 ユーザーは再起動後にコンテナを手動で開始する必要があります。 以下に、その詳細な手順を示します。

1. Cloud Exchangeディレクトリにアクセスしてください。

$ cd <ce_directory>

なお、CEをVMとして使用する場合、Cloud Exchangeディレクトリは以下のとおりです。

/opt/cloudexchange/cloudexchange

2. コンテナの状態を確認してください。

$ podman-compose ps

3. Cloud Exchange開始:

$ ./start

UbuntuやCentOSなどの他の仮想マシン上でDockerを使用しているユーザーは、コンテナの再起動に関して手動で操作する必要はありません。Dockerには、再起動後にコンテナが自動的に再起動することを保証する自動再起動機能が含まれています。この自動再起動機能により、再起動後に手動で操作する必要なく、スムーズな操作が可能になります。

Cloud Exchange (CE) は、再起動、移行、またはインフラストラクチャの変更後にアクセスできなくなる場合があります。これは、Web UI が読み込まれていない、またはコア サービスの開始に失敗しているとして発生する可能性があります。
よくある理由は、MongoDB 5.0+ (CE で使用) に必要な AVX (Advanced Vector Extensions) サポートがシステムにないことです。

Typical Symptoms

• CE web interface shows errors (e.g., 400 Bad Request).
• mongodb-primary および core コンテナはexited状態ですが、その他のコンテナ (UI、RabbitMQ) は引き続き実行されています。

CEは以前は正常に動作していましたが、再起動、移行、またはアップグレード後にアクセスできなくなりました。

Root Cause

MongoDB 5.0以降では、 AVX instructionsのCPUが必要です。ホストマシン（物理マシンまたは仮想マシン）がAVXをサポートしていない場合、またはAVXが無効になっている場合、MongoDBは開始できず、その結果、コアCEサービスが停止します。

Steps to Troubleshoot

• Check container status
  podman ps -a

• mongodb-primaryコンテナとcoreコンテナの状態を確認してください。

• Review MongoDB logs
  CEディレクトリから、以下を実行します。
  sudo docker-compose logs -f mongodb-primary | grep "AVX"

• AVX サポートが不足している場合は、次のような警告が表示されます:
  MongoDB 5.0 以降では AVX サポート付きの CPU が必要ですが、現在のシステムにはそれが搭載されていないようです。

• Check AVX availability
  lscpu | grep -i avx

Resolution

• ホストまたは仮想マシン上でAVXサポートを確認し、有効にするようIT/VM teamに依頼してください。
• 仮想マシンの場合、AVXがexposed to the guest systemあることを確認してください。

AVXを有効にした後、CEサービスを再起動してください。

• podman-compose down && podman-compose up -d

MongoDBとコアコンテナが正常に起動し、CE UI
アクセスできること
確認してください。Next Step: AVXが有効になっているにもかかわらず問題が解決しない場合は、サポートチームにログやスクリーンショットを共有してください。そうすれば、さらにサポートできます。

Issue Overview

Cloud Exchangeホストマシンでコマンドを実行しようとすると、「ホスト名が解決されません」というエラーが表示され、DNS解決ができないためにCloud Exchange Cloud Exchange UIにアクセスできません。

Typical Symptoms

• Cloud Exchangeのユーザーインターフェースにアクセスできません。
• Cloud Exchange再起動しようとすると、ホスト名を取得してもエラーが解決しません。

Root Cause

すべてのDNS設定を含むファイルが削除されました。このため、マシンはホスト名を解決できません。

Steps to Troubleshoot

1. 基本的なDockerコマンドを実行して、 Cloud Exchangeサーバー上のDNS解決を確認してください。

   sudo docker ps

2. 「名前が解決できません」というエラーが表示された場合は、次の手順に進んでください。
3. resolv.conf ファイルの存在を確認してください。

   cat /etc/resolv.conf

4. resolv.conf ファイルが存在しない場合は、作成して DNS サーバーの詳細情報を追加してください。

   vi /etc/resolv.conf

5. DNSサーバーのエントリを以下の形式で追加してください。

   nameserver [DNS_SERVER_IP_1] 
   nameserver [DNS_SERVER_IP_2]

6. このファイルを保存してください。
   • Press Esc
   • タイプ :wq!
   • Press Enter (key)
7. DNS設定の変更を適用するには、マシンを再起動してください。
8. すべてのDockerコンテナが正しく動作していることを確認してください。

   sudo docker ps

9. 以下のコンテナが起動して稼働していることを確認してください。

   cloudexchange_ui_1
   
   cloudexchange_core_1
   
   cloudexchange_rabbitmq-stats_1
   
   Cloudexchange_mongodb-primary_1

10. それでも問題が解決しない場合は、診断ログを収集し、サポートケースを作成してください。診断ログ生成のトラブルシューティングについては、 「診断ログの生成」を参照してください。

Issue Summary:

• RHEL サーバーに Cloud Exchange をインストールしている際に、「マシンの Podman/Podman-compose/Podman-plugins のバージョンを確認できませんでした」というエラーが表示され、podman、podman-compose、podman-plugins が既にサーバーにインストールされていることを、こちらのガイドライン ドキュメントに従って確認済みです。

Common Symptoms:

まず、サーバー上のPython3のバージョンを確認してください。

• お使いのマシンにインストールされているPython3のバージョンをご確認ください。 コマンド： python3 --version

Python 3.6.8を使っている場合 または、サーバーに古いバージョンがインストールされている場合、それが問題の原因です。

Root Cause:

• Python 3.6.8を使用そして、それに関連するpip3によってpodman-composeがインストールされ、競合問題が発生します。

Troubleshooting Steps/Resolution:

Cloud ExchangeはPython 3.11以上を使用していることにご注意ください。以下のドキュメントでも強調しています:/en/Cloud Exchange-system-requirements#system-specifications

したがって、podman-composeを削除してからpython3.11をインストールし、その後podman-composeを再インストールすることをお勧めします。以下の手順に従ってください。

• Remove podman-compose using command:
  sudo pip3 uninstall podman-compose
• Install python3.11 and setting alternative:
  yum install -y python311
yum module enable python311
alternatives --set python3 /usr/bin/python3.11
python3 --version (should point to Python 3.11.x)
• Podman-compose installation commands:
  sudo pip3 install podman-compose
sudo ln -s /usr/local/bin/podman-compose /usr/bin/podman-compose (podman-composeへのソフトリンク)

これらの手順が完了したら、podman-compose のバージョンを確認できます。 先ほど共有したコマンドを実行してから、セットアップスクリプトの実行によるCloud Exchangeインストールに進みます。

Reference:

• ご参考までに、CEシステムの仕様が強調表示されているこちらのガイドをご覧ください： CEシステムの仕様

問題の概要： 新規インストールまたはアップグレード/移行中に、セットアップスクリプトが以下のエラーメッセージとともに失敗します。

pyyaml に互換性のないバージョンが見つかりました。依存関係 (pyyaml>=6.0.0 | python-dotenv>=0.20.0、<=1.0.0 | pymongo>=4.6.3，<=4.7.3) は、•/setup スクリプトを実行する前に満たされている必要があります。

よくある症状: Pythonの依存関係が存在しないか、またはインストールされているバージョンが現在インストールされているCEバージョンと互換性がない可能性があります。

根本的な原因：

CEを下位バージョンから上位バージョンにアップグレードしたことにより、サポートされている最小バージョンがアップグレードされたか、新規インストール時にすべての依存関係が正しくインストールされなかった可能性があります。

トラブルシューティングの手順／解決策：

まず、環境が保存されているcloudexchangeのルートディレクトリに移動します。

Cloud Exchange as a VM Deployment

cd /opt/cloudexchange/cloudexchange

If using Containerized Deployment

cd  <ta_cloud_exchange_directory>

仮想環境を再現する

python3 -m venv --clear .cevenv

仮想環境をアクティブ化する

source ./.cevenv/bin/activate

必要なパッケージをインストールします

pip3 install "pyyaml>=6.0.0" 

pip3 install "python-dotenv>=0.20.0,<=1.0.0" 

pip3 install "pymongo>=4.6.3,<=4.7.3"

環境を無効化する

deactivate

問題の概要: HA セットアップ中に、入出力エラーのためセットアップスクリプトが失敗します。

トラブルシューティングの手順／解決策：

まず、そのノードの環境情報が保存されているcloudexchangeのルートディレクトリに移動します。
Cloud Exchange as a VM Deployment

cd /opt/cloudexchange/cloudexchange

If using Containerized Deployment

cd  <ta_cloud_exchange_directory>

このコマンドを実行してください（最初のセカンダリノードの場合はレプリカ1、2番目のセカンダリノードの場合はレプリカ2）。

gluster volume remove-brick CloudExchange replica 1 <node_ip>:/opt/shared/gluster/bricks/1/brick force 

これをプライマリノードで実行してください

gluster peer detach <replica node_ip>

umount /opt/shared/data

rm -rf /opt/shared/*

発行デスクリプション

Cloud Exchangeのコンテナ化されたデプロイメントのセットアップスクリプトの実行中に、ユーザーがhub.docker.comに接続しようとした際に、接続タイムアウトエラーが発生します。これは、ネットワーク設定で接続が許可されているように見える場合でも発生します。

根本的な原因

この問題は、Docker Hub（Docker側）における最近の変更に関連しており、Cloud Exchange自体とは関係ありません。

これらの変更により、Docker Hub の Cloud Exchange セットアップの前提条件チェックが、特にコンテナ化されたデプロイメントにおいて失敗するようになっています。

Cloud ExchangeをVMとしてデプロイしているユーザーは、この問題の影響を受けません。

 暫定的な回避策

製品チームが恒久的な修正に取り組んでいる間、 以下の回避策をご利用ください。

1. Standalone Deployments

スタンドアロン展開の場合のみ、セットアップスクリプトで –ignore-failures フラグを使用することで、失敗した前提条件チェックをスキップできます。

• python3 ./setup --ignore-failures 

2. High Availability (HA) Deployments

高可用性（HA）構成での導入については、セットアップに関するサポートが必要な場合は、サポートチームにお問い合わせください。

Resolution

チームはこの問題の解決に向けて積極的に取り組んでいます。この既知の制限事項に対処するアップデートについては、リリースノートをご確認ください。

Issue Overview

Cloud Exchange HA クラスターにセカンダリ ノードを追加すると、ネットワークのスループットとレイテンシによっては、新しい Docker イメージのプルに時間がかかる場合があります。このため、新しいノード上のコンテナは自動的に開始されません。

Steps to start the services on new node

1. 新しく追加したセカンダリノードのCEインストールディレクトリに移動します。
2. 開始スクリプトを実行する
   sudo ./start
3. 開始スクリプトの完了後、新しく追加したノードのサービスのステータスを確認します。

シナリオ

このガイドでは、GlusterFSを完全に削除し、残っているFUSEの状態をすべてクリアして、エラーを恒久的に解決する手順を説明します。

Transport endpoint is not connected

この問題を解決するには、パッケージのアンインストール、残っているFUSEとマウントキャッシュのクリーンアップ、そしてサーバーの再起動という3つの手順が必要です。いずれかの手順を省略すると、システムが破損する可能性があります。

前提条件

• 影響を受けるサーバー上でroot権限またはsudo権限が必要です。
• 続行する前に、GlusterFSサービスを停止する必要があります。
• メンテナンス期間をスケジュールしてください。再起動が必要です。

Resolution

ステップ1 — GlusterFSサービスを停止します。

• For RHEL Operation System

systemctl stop glusterd
systemctl disable glusterd

• For Ubuntu Operating System

Give sudo its own private PATH (secure_path)

使う 3.11 を指しつつ、システム全体の /usr/bin/python3 はそのままにしておきます。

# 1. install python3.11 
sudo dnf install -y python3.11

# 2. sudo-only bin dir with a python3 -> 3.11 symlink
sudo mkdir -p /usr/local/sudo-bin
sudo ln -sf /usr/bin/python3.11 /usr/local/sudo-bin/python3

# 3. Write the sudoers override LOCALLY first, then copy in
cat > /tmp/python311_secure_path << 'EOF'
Defaults secure_path="/usr/local/sudo-bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
EOF

# 4. Validate BEFORE installing into /etc/sudoers.d
sudo visudo -cf /tmp/python311_secure_path

# 5. Install (only if step 4 said "parsed OK")
sudo install -m 0440 -o root -g root /tmp/python311_secure_path /etc/sudoers.d/python311_secure_path
rm -f /tmp/python311_secure_path

# 6. Re-validate the whole sudoers config
sudo visudo -cf /etc/sudoers

Add an alias Python3 -> 3.11 for Interactive Shells (normal user + root)

# normal user (~/.bashrc)
echo "alias python3=/usr/bin/python3.11" >> ~/.bashrc

# root (/root/.bashrc) — needed separately, root has its own rc file
sudo bash -c 'echo "alias python3=/usr/bin/python3.11" >> /root/.bashrc'

# apply to current shells
source ~/.bashrc
sudo -i bash -c 'source /root/.bashrc'

Configure a Systemd Drop-In Override 

# add a drop-in override (survives ./setup regenerating the base unit file)
sudo mkdir -p /etc/systemd/system/cloud-exchange.service.d
sudo tee /etc/systemd/system/cloud-exchange.service.d/override.conf << 'EOF'
[Service]
Environment="PATH=/usr/local/sudo-bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
EOF

#If the Management Server is running, perform a restart.
sudo systemctl daemon-reload
sudo systemctl restart cloud-exchange

Validate Changes

sudo python3 --version   # -> Python 3.11.x   (via /usr/local/sudo-bin/python3)
python3 --version        # -> python3.11.x       (system default)

シナリオ: 5.1.0 に移行した後、CEコアコンテナが再起動され、コアコンテナのログに以下のエラーが記録されています。

影響：CE（継続教育）は利用しにくい。

解決策：診断ログを添えてNetskopeサポートチームにお問い合わせください。

./開始の実行中に InvalidReplicaSetConfig などのエラーが発生する 高可用性を備えたCloud Exchangeをデプロイする際のスクリプト

MongoDBレプリカセットの初期化中に、「レプリカセットmongo_replic_setの新しい構成で{version: 1, term: 0}が指定されているホストが、このノードにマッピングされていません。」というエラーメッセージが表示される場合があります。この問題は、MongoDBコンテナがセットアップスクリプトで指定されたIPアドレスまたはホスト名を介して接続する際に問題が発生した場合によく発生します。この問題を効果的に解決するには、必要なポートがファイアウォールを通過するように設定することが不可欠です。MongoDBのスムーズな初期化を実現するには、これらの重要なポートへのアクセスを許可し、レプリカセット内での円滑な通信と動作を可能にすることが不可欠です。許可すべきポートは以下のとおりです。

• 4369 (RabbitMQ ノードと CLI ツールによって使用されるピア検出サービス)
• 5672 ( AMQP 0-9-1およびAMQP 1.0クライアント（TLSなしおよびTLSあり）による)
• 15672 (HTTP APIクライアント、管理UI、およびrabbitmqadmin、TLSなしおよびTLSあり)
• 25672 (ノード間および CLI ツール通信に使用)
• 35672 (CLI ツール通信に使用)
• 27017（mongodおよびmongosインスタンスのデフォルトポート）
• 選択されたUIポート（デフォルトはHTTPSの場合は443、HTTPの場合は80）（UIおよびノード間ヘルスチェックへのアクセス用）

ポート番号を許可するには、次の手順を実行します。

1. ポートの状態を確認してください：

   Ubuntuの場合：

   $ sudo ufw status PORT_NUMBER

   Red Hatの場合：

   $ sudo firewall-cmd --list-ports=PORT_NUMBER/tcp

2. ポートが許可されていない場合は、以下の手順を実行してください。

   Ubuntuの場合：

   $ sudo ufw allow PORT_NUMBER

   Red Hatの場合：

   $ sudo firewall-cmd --zone=public --add-port=PORT_NUMBER/tcp --permanent

3. ファイアウォールを再読み込みしてください。

   Ubuntuの場合：

   $ sudo ufw reload

   Red Hatの場合：

   $ sudo firewall-cmd --reload

このエラーは、Cloud Exchange を 3.x/4.x からアップグレードする際に発生します。最新バージョンへ：

ta_cloud_exchange_mongodb-primary_1 |

{"t":{"$date":"2025-01-15T10:17:50.744+00:00"},"s":"F", "c":"CONTROL",

"id":20573, "ctx":"initandlisten","msg":"Wrong mongod version","attr":{"error":"UPGRADE PROBLEM: Found an invalid featureCompatibilityVersion document (ERROR: Location4926900: Invalid featureCompatibilityVersion document in admin.system.version: { _id:

"featureCompatibilityVersion", version: "4.4" }.

Primary Observed Issue: 移行／アップグレードに失敗しました。

Follow these steps to analyze the issue you are facing

1. まず、DockerとDocker Composeのバージョンを確認してください。バージョンを確認するには以下のコマンドを使用します
   • docker version
   • docker compose version/docker-compose version。
2. Dockerのバージョンが25未満の場合は、バージョンをアップグレードする必要があります。
3. この文書に記載されている指示に従ってください。https://docs.docker.com/engine/install/ubuntu/ 。
4. docker-compose については、使う このドキュメントを参照してください。 https://docs.docker.com/compose/install/standalone/ 。

入力されたメンテナンスパスワードが正しくありません

移行またはアップグレード処理中にセットアップスクリプトを実行すると、ユーザーは以下のエラーメッセージに遭遇します。このコマンドの実行中にエラーが発生しました。エラー: コマンド 'docker exec mongo-migration mongo -u root –password <pass> admin –eval 'db.adminCommand({setFeatureCompatibilityVersion: “5.0”})” がゼロ以外の終了ステータス 1 を返しました。メンテナンスパスワードの誤りによって発生したエラーを確認するには、ユーザーは指定されたコマンドを実行する必要があります。 podmanまたはdockerのいずれか：

$ sudo docker ps

$ sudo podman ps

「mongo-migration」という名前のコンテナが実行されている場合、移行プロセス中に誤ったメンテナンスパスワードが追加されたことを示しています。 

このような状況の場合は、展開タイプに基づいてセットアップスクリプトを再度実行する必要があります。さらに、以前のCloud Exchangeのセットアップ時に使用したメンテナンス パスワードと同じパスワードを入力する必要があります。 コンテナ化されたCEまたはHA構成のCEの場合、セットアップスクリプトを再実行するコマンドは次のとおりです。

$ sudo python3 ./setup

CEをVMインスタンスとして使用する場合、セットアップスクリプトを再実行するコマンドは次のとおりです。

$ sudo ./setup.

ユーザーが実行中のコンテナを見つけられない場合は、以下のトラブルシューティング手順を参照する必要があるかもしれません。

互換性のないMongo機能互換性バージョン

移行またはアップグレード処理中にセットアップスクリプトを実行すると、以下のエラーメッセージが表示されます。デーモンからのエラー応答: コンテナ <Container_ID> は実行されていません。コマンドの実行中にエラーが発生しました。エラー: コマンド 'docker/podman exec mongo-migration mongo -u root –password <pass> admin –eval 'db.adminCommand({setFeatureCompatibilityVersion: “5.0”})” がゼロ以外の終了ステータス 1 を返しました。このエラーの発生を防ぐには、以下の手順に従ってください。
For those who are utilizing a Containerized CE, follow these steps:
1. このコマンドを実行します。

$ echo MONGO_COMPATIBILITY=True >> .env

2. 変更内容を確認するには、 コンテナ化されたCEインスタンスの場合、以下のコマンドを実行してください。

$ cat .env

3. セットアップスクリプトを再度実行します。以下のコマンドを使用する場合:

$ sudo ./setup

If you are using CE as HA (Containerized) based instance, follow these steps:
1. 次のコマンドを実行します。

$ echo MONGO_COMPATIBILITY=True >> <shared_drive>/config/.env

2. 変更を確認するには、 HAベースのインスタンスとしてCEに対して以下のコマンドを実行します。

$ sudo cat <shared_drive>/config/.env

3. 現在のノードでセットアップスクリプトを再度実行します。今回はエラーは発生しないはずです。

$ sudo ./setup

If you are using CE as OVA instance, follow these steps:
1. 次のコマンドを実行します。

$ sudo vi /opt/cloudexchange/cloudexchange/.env

CEでVMベースのインスタンスとしてHAを選択した場合は、次のコマンドを実行してください。

$ sudo vi <shared_drive>/config/.env

2. .env ファイルに次の行を挿入します。ファイルを開き、変更内容を保存することを忘れないでください。

MONGO_COMPATIBILITY=True

3. 以下のコマンドを使用して、セットアップ スクリプトを再実行します。

$ sudo ./setup

 シナリオ：顧客がv5.1.1への移行を試みる場合古いバージョンのHAからHAを復元するには、restore_ha_backupスクリプトを実行する必要があります。しかし、特定のシェルバージョン、特にVMイメージとしてのUbuntu 22.04/CEでは、このスクリプトは環境変数のエクスポート中にエラーが発生します。

解決策：このエラーの発生を防ぐには、./restore_ha_backup を実行する代わりに、以下の手順に従ってください。スクリプト。

1. 必要な環境変数をエクスポートするには、次のコマンドを実行してください。
   $ export MONGO_INITDB_ROOT_PASSWORD=<Enter_maintenance_password>
$ export HA_PRIMARY_NODE_IP=<Enter_current_node_ip>
   
2. MongoDB コンテナを開始するには、次のコマンドを使用します。
   
   • UbuntuなどのDockerベースのシステムでは、以下のコマンドを実行してください。
     $ sudo docker compose -f docker-compose-ha.yml up mongodb-primary -d
   • RHELなどのPodmanベースのシステムでは、以下のコマンドを実行してください。
     $ sudo podman-compose -f podman-compose-ha.yml up mongodb-primary -d
3. このコマンドを実行して、移行後に新しいプライマリ IP をクラスターに割り当てます。以下のコマンドを使用します。
   
   • UbuntuなどのDockerベースのシステムでは、以下のコマンドを実行してください。
     $ sudo docker compose -f docker-compose-ha.yml exec mongodb-primary bash -c "mongosh -u root -p $MONGO_INITDB_ROOT_PASSWORD --eval 'cfg = rs.conf();cfg.members[0].host = "$HA_PRIMARY_NODE_IP:27017";rs.reconfig(cfg, { force: true })'"
   • RHELなどのPodmanベースのシステムでは、以下のコマンドを実行してください。
     $ sudo podman-compose -f podman-compose-ha.yml exec mongodb-primary bash -c "mongosh -u root -p $MONGO_INITDB_ROOT_PASSWORD --eval 'cfg = rs.conf();cfg.members[0].host = "$HA_PRIMARY_NODE_IP:27017";rs.reconfig(cfg, { force: true })'"
4. MongoDBコンテナを停止するには、以下のコマンドを実行してください。
   
   • UbuntuなどのDockerベースのシステムでは、以下のコマンドを実行してください。
     $ sudo docker compose -f docker-compose-ha.yml down -v
   • RHELなどのPodmanベースのシステムでは、以下のコマンドを実行してください。
     $ sudo podman-compose -f podman-compose-ha.yml down -v

Issue Summary: サーバーのRHEL OSアップグレード後、 Cloud Exchange起動しません。

Common Symptoms: Cloud Exchangeコンテナを起動するための開始スクリプトを実行しようとした際に、システムにpodmanまたはpodman-composeが存在しないことに関連するエラーが発生している可能性があります。

根本的な原因：

サーバーのOSアップグレードが原因で、これらのファイルとパッケージがお客様のマシンから削除された可能性があります。したがって、正確な原因については、ITチームまたはVMチームにご確認いただくことをお勧めします。

トラブルシューティングの手順／解決策：

Podman、Podman-compose、およびPodman-pluginsはCloud Exchangeの前提条件であるため、お使いのマシンに再度インストールする必要があります。 

それでは、以下の手順に従ってください。

• Podmanのインストールコマンド：
  sudo yum install podman
• Podman-composeのインストールコマンド：
  sudo pip3 install podman-compose
• podman-compose のソフトリンクを作成します:
  sudo ln -s /usr/local/bin/podman-compose /usr/bin/podman-compose 
• Podmanプラグインのインストールコマンド：
  sudo yum install podman-plugins

これらの依存関係がインストールされたら、次のコマンドを実行してPodmanシステムの詳細を再作成してください： sudo podman system reset

これらの手順を実行した後、 Cloud Exchange再起動してください。 次のコマンド：

1. sudo ./stop
2. sudo ./start

 これで、以前の設定を失うことなく、お使いのマシンでCloud Exchange開始できるはずです。

Cloud ExchangeでNetskope Log Shipperプラグインを設定する際に、検証エラーが発生する場合があります。

TENANT Netskope Tenant (Required) []: Validation error occurred, Received exit code 403, Forbidden, Verify the V1, V2 API Token provided in the configuration parameters.

Typical Symptoms

• 権限が正しく見える場合でも、問題が発生する。
• プラグイン設定の保存中にエラーバナーが表示されました。
• メッセージには、無効または不十分なV1またはV2 APIトークンが含まれています。

Root Cause

• Cloud Exchange v5.1.1（CLSプラグインv2.2.0以降）以降では、新しいクライアントステータスイベントタイプが導入されました。
• このイベント タイプはエンドポイントを使用します:
  /api/v2/events/dataexport/iterator
/api/v2/events/datasearch/clientstatus  
• この V2 API トークンには、このエンドポイントに対する読む + 書き込み権限が必要です。

Steps to Troubleshoot

1. プラグインのバージョンを確認してください。CLS v2.2.0以上である必要があります。
2. トークンの権限を確認する:
   • /api/v2/events/dataexport/ * および/api/v2/events/datasearch/clientstatusエンドポイントがすべて含まれていることを確認してください。
   • /api/v2/events/dataexport/iterator に読む + WRITE があることを確認します。
3. 適切な権限を持つV2 APIトークンを更新または再作成してください。

更新されたトークンをCLSプラグインの設定に保存してください。

Resolution

• 必要なデータエクスポート権限を追加します (読む + イテレータの WRITE)。
• CLS設定の保存を再度お試しください。
• クライアントステータスが不要な場合は、トークンが更新されるまで、このイベントタイプを一時的に選択解除してバイパスしてください。
  

次のようなエラーが表示されます。

- Error: Value error, please check the Tenant Name field has no special characters, ensure V1 and V2 tokens are valid.

Troubleshooting Steps

1. まず、NetskopeテナントでREST API v2のREST APIステータスが有効になっていることを確認してください。
   
2. ここに記載されているとおり、必要な Netskope エンドポイントの権限/スコープを使用して REST API v2 トークンを作成したことを確認してください。
3. 既存の REST API v2 トークンを確認し、必要に応じて、上記のドキュメントに従ってNetskopeエンドポイントのアクセス許可/スコープを変更します。 もう一度試して、 NetskopeテナントをCloud Exchange UIに保存してください。
4. 問題が解決しない場合は、Cloud Exchangeがデプロイされているホストマシンで、以下のcurlコマンドを実行してください。

   注記

   上記のコマンドを実行する前に、 <tenant-name>をNetskopeテナント名に、 <V2 token>を既存のREST API v2トークンに置き換えてください。

   curl --location https://<tenant-name>.goskope.com/api/v2/events/dataexport/events/page?index=tenant --header 'Netskope-Api-Token: <V2 token>'

Command Output
コマンドの出力でIP アドレス xxxx に対して Unauthorizedと表示された場合は、Netskope テナントの IP Allowlist のカスタム IP アドレス セクションにハイライト表示された IP アドレスを追加してください (無効になっている場合は有効にしてください)。

Path for IP Allowlist

NetskopeテナントにログインしてSettings > Administration > IP Allowlist > Custom IP Addressesに移動してください。

Cloud ExchangeのUIでこのバナーが表示された場合、REST API V2トークンの有効期限が切れていることを示しています。

Follow these steps to resolve this error

1. Netskopeのテナントで Settings > Tools > REST API V2 に移動し、APIトークンを選択します。3つの点のドロップダウンをクリックして、 Change Expiration Dateを選択します。
2. 今度はトークンを再発行する必要があります。APIトークンを取得するには、3つの点のドロップダウンをクリックしてReissueを選択してください。
3. 新しいトークンをコピーし、それをCloud Exchange Netskopeテナント構成で使用します。

SSOにはトップレベルドメイン（TLD）が必要です。URLをマッピングする際にホスト名にTLDを追加せず、CEでSSOを有効にすると、顧客に「無効なホスト名です。トップレベルドメインが必要です」というエラーが表示されます。これは、適切なTLD（ Netskopeなど）を追加することで解決できます。

このようなエラーが表示される場合は、Netskope CEがデフォルトでTLSv1.3のみをサポートしているためです。このエラーを解決するには、Netskope CEがTLSv1.2とTLSv1.3の両方で動作するように設定する必要があります。そのためには、セットアップスクリプトからTLSバージョンを変更する必要があります。セットアップスクリプトを再度実行し、次の質問に「はい」と入力してください。

Do you want to enable TLSv1.2 along with TLSv1.3 for CE UI.

次に、開始スクリプトを実行します。

証明書の有効期限が切れている場合は、以下の手順に従って証明書を再生成してください。

1. 全てのコンテナを下ろしてください。
2. 証明書ファイル (cte_cert.crt、cte_cert_key.key)データ/ssl_certsフォルダから。
3. 証明書を再生成するために、セットアップスクリプトを再度実行してください。以下の質問に「https」と入力してください。

   Do you want to access CE over HTTP, or HTTPS (HTTPS is recommended)? https

4. 開始スクリプトを実行します。

管理者パスワードをリセットするには、 アカウント設定 セクションの 「パスワードのリセット」 を参照してください。CE管理者がパスワードをリセットした後、必ずアカウント設定からパスワードを変更してください。

他のユーザーのパスワードをリセットするには、スーパー管理者はSettings > Usersからユーザーのパスワードを更新し、右側の編集アイコンをクリックします。

SSOの設定を変更するには、SSOを無効にする必要があります。 CE UIのSSO設定タブにあるトグルスイッチをオンにしてください。 そのためには、以下の手順に従ってください。

1. まず、Okta の SSO 設定に関する詳細情報（ID プロバイダー発行者 URL、ID プロバイダー SSO URL、ID プロバイダー SLO URL、および公開 x509 証明書）をファイルに保存します。
2. 次にSSOを無効にします CE UIのSSO設定ページにあるトグルスイッチを使用します。
3. SSOを無効化した後、ドメインの変更は、変更後のドメインに応じて、サービスプロバイダーエンティティID、サービスプロバイダーACS URL、およびサービスプロバイダーSLS URLに反映されるはずです。
4. CE UI でこれが表示されたら、SSO を再度有効にしてください。 トグル。
5. 最初のステップで保存した詳細情報をファイルから再度入力してください。

なお、変更後のドメインに合わせて、OktaなどのIdPのサービスプロバイダーエンティティID、サービスプロバイダーACS URL、およびサービスプロバイダーSLS URLも更新する必要があることに注意してください。

問題の概要

アップグレード完了後、 Cloud Exchangeウェブサイトの UI に SSL 証明書の有効期限切れバナーが表示されるようになりました。

トラブルシューティングの手順

1. Cloud ExchangeホストマシンのCLIにアクセスしてください。
2. Cloud Exchange ディレクトリに移動してください。
3. Cloud Exchangeサービスを停止します。

   sudo ./stop

4. 既存のSSL証明書を削除します。

   rm -rf data/ssl_certs/cte_cert.crt
   rm -rf data/ssl_certs/cte_cert_key.key

5. これが完了したら、セットアップスクリプトを再度実行してください。

   sudo python3 ./setup

6. なお、Cloud ExchangeをVMとしてデプロイしている場合は、以下を実行してください。

   sudo ./setup

7. ◇ 開始スクリプトを実行します。

   sudo ./start

これらの手順で最新のSSL証明書が生成されます。

Issue Overview

HA 構成中、すべてのノードはプライマリ ノードと同じ JWT シークレットを使用する必要があります。 プライマリノードの設定中に生成または構成された JWT シークレットが利用できない場合は、新しい JWT シークレットを生成し、クラスタ内のすべてのノードで構成してください。

Steps to Regenerate JWT TOKEN

1. CEのインストールディレクトリ（プライマリノード）に移動します。展開タイプに応じて、適切な手順に従ってください。
   • コンテナ化されたCEデプロイメント
     cd <ta_cloud_exchange_directory_path>
   • CEをVMとしてデプロイ
     cd /opt/cloudexchange/cloudexchange
2. コンテナを停止してください。
   sudo ./stop
3. 特定のJWTシークレットを設定するには、cloudexchange.configファイルを変更し、JWT_SECRETの値を指定します。
   sudo cp cloudexchange.config.example cloudexchange.config
sudo vi cloudexchange.config

4. セットアップスクリプトを実行します。
   sudo ./setup
5. コンテナを再起動してください。
   sudo ./start

シナリオ：CEは、入力フィールドのデータ型（文字列、数値、またはブール値）を自動的に検出し、データ取得時に、新しいデータ型に基づいてすべてのCEフィルタビューの演算子を適切に調整します。フィールドのデータ型が変更されると、そのフィールドに設定されているビジネス、ミュート、または重複排除ルールが適用されると、赤いエラー アイコンが表示されます。 これらのルールは編集オプションから再設定する必要があります。

影響：受信アラート/イベント/ログに対して、フィルタリング、変換、チケット作成、重複排除、ミュートルール評価などのモジュール固有のライフサイクルタスクが停止され、サードパーティへの受信データ処理がスキップされます。無効なルールが設定されている場合、CE は受信したアラートまたはイベントのバッチを処理できず、ログタブにエラーメッセージが表示されます。

解決策：編集オプションを使用して、これらのルールを再設定する必要があります。

1. それぞれのビジネスルールページに移動してください。
2. Editをクリックしてください。
3. 問題に対処するために、必要に応じてフィルターを修正してください。
4. 変更を適用するには、 Saveをクリックしてください。

シナリオ: SIEM を設定してその特定の SIEM を削除し、プラグイン設定で指定された初期範囲の履歴プルが進行中にそれを再設定すると、CE は複数のタスクを作成します (1 つは SIEM マッピングの作成時間、もう 1 つは SIEM マッピングの再設定)。 

これを解決するには、CE を再起動して停止スクリプトと開始スクリプトを使用し、 Log shipper > SIEM Mappingsで履歴範囲との手動同期を実行します。

シナリオ：Netskopeに脅威のIoCを共有する際に、このエラーが表示される場合があります。

影響：IoC（侵害指標）はNetskopeに共有されますが、指標にタグ付けする機能に影響が出ます。これはIoCの削除機能にも影響を与える可能性があります。

解決：

1. Settings > Repositoryに移動してCheck for Updatesをクリックすると、デフォルトリポジトリの更新を取得できます。
2. Update Pluginsをクリックし、Netskope Threat Exchange プラグインを選択してからSaveをクリックし、画面の指示に従ってください。
3. 次の共有処理の実行まで待ってから、監査ログにエラーが表示されなくなっているかどうかを確認してください。

シナリオ：古いCEから移行した後、デフォルトプラグインリポジトリからアップデートを取得する際に、このエラーが発生します。

影響：デフォルトリポジトリのGithubからプラグインのアップデートを取得できなくなります。

解決：

1. SSHでCEインスタンスに接続し、Cloud Exchangeのインストールパッケージディレクトリに移動します。
2. すべての追跡されていないファイルを削除するには、次のコマンドを使用します: (RHEL ベースの OS では docker-compose の代わりに podman-compose を使用します)。

$ docker-compose exec -w /opt/netskope/repos/Default core git clean -df

上記のコマンドを実行中にエラーが発生した場合は、このコマンドを試して追跡されていないファイルを削除してください。

$ cd data/repos/Default (cd <shared_drive>/repos/Default for HA deployment) 
$ sudo rm -rf crowdstrike_identity_protect_ztre/ crowdstrike_ztre/ microsoft_entra_id_ztre/ mimecast_ztre/ netskope_ztre/ okta_ztre/

この問題に対処するには、ビジネスルールとSIEMのマッピングが正しいことを確認することが不可欠です。 正しいことを確認することが重要です。 さらに、プラグインの設定プロセス中に、すべてのパラメーターが正確に入力されていることを確認してください。共有設定を確認し、共有する予定のIoCと一致していることを確認することも重要です。共有フィルターが正しくない場合は、共有条件を適切に調整してください。

設定ミスによって失われた可能性のある過去のデータを取得するには、共有設定を削除してから再度追加することを検討してください。これらの手順を踏むことで、IoC（侵害指標）が意図した脅威の発生源と適切に共有されることを保証できます。

Netskope 、ドメインの前にワイルドカード文字がある URL のみを受け入れます。それ以外の URL は、Threat Exchange が送信を試みる際に拒否されます。 したがって、 *.google.comは Netskope テナントに受け入れられますが、 google.com/*は受け入れられません。Threat Exchangeデータベースにワイルドカードが含まれている場合は、共有するために手動でタグ付けする必要があります。

デフォルトでは、アップロードされたすべてのプラグインは./data/custom_pluginsディレクトリ内に保存されます。ただし、これはdocker-composeで別のディレクトリをマウントすることで変更できます。また、管理者はカスタムプラグインをダウンロードするためのリポジトリを追加することもできます。これは設定メニュー内で設定できます。これは、CEインスタンスにプラグインを追加する最良の方法であり、CTO、CLS、およびCREプラグインを追加できる唯一の方法です。

シナリオ：5.1.0に移行後ユーザーは、CTOモジュールの既存のビジネスルールを更新する際に、以下のエラーが表示される場合があります。

影響：ルールを再定義するまで、既存のルールを更新することはできません。

解決策：UIからビジネスルールを再定義し、更新する。

プラットフォームはデフォルトで過去7日間のIoC（侵害指標）を検索します。IoC（侵害指標）が多すぎる場合（100万以上）、かつフィルターが選択されていない場合、検索パフォーマンスが低下します。

提案される解決策：フィルターを適用し、検索条件を絞り込むことを検討してください。データセットのレコード数が約10万件以下の場合に、パフォーマンスが最も向上します。

コンテナのアップグレードまたは再起動を行う前に、アクティブな設定を含むカスタムプラグインがNetskope CEにアップロードされていることを確認してください。このような場合は、アップグレード後にカスタムプラグインをアップロードしてください（ 「カスタムプラグインのアップロード」 の 「カスタムCTEプラグインの作成」 を参照してください）。カスタムプラグインをアップロードした後も設定は保持され、通常の動作が復元されます。

送信API呼び出しにプロキシが必要かどうかを確認してください。ネットワーク構成においてHTTP API呼び出しにプロキシが必要とされ、実際にプロキシが設定されている場合、プラグインの動作に影響が出ます。

提案された解決策：

1. Settings > General > Proxyへ移動してください。
2. 既存の設定を編集して、 Use System Proxyを有効にします。

CEは、プラグインのタスク実行のために内部スケジューリング機構を利用しています。ワーカーは、キューからタスクを一つずつ選択して、プラグインのタスクを実行します。システムで利用可能なワーカーの数は、コアの数によって決まります。利用可能なワーカーがプラグインタスクの処理でビジー状態の場合、既にキューに入っているタスクは、既存のワーカーが利用可能になるまで待機する必要があります。この状況は通常、処理すべきデータが多い初期データ取り込み時に発生する可能性があります。

提案される解決策：設定済みのプラグインの数が多く、それらのプラグインの処理速度が常に遅い場合は、システムのコア数を増やすことを検討してください。初回データ取り込み後、システムはバックログを自動的に取得し、増分データ量が大きくない場合は正常に動作する必要があります。

いずれかの設定に赤い警告アイコンが表示されている場合、その設定に従って接続されているシステムからデータをポーリングする際に、1つ以上の問題が発生したことを示しています。これは、API、プロキシ、またはSSLの設定に関連している可能性があります。

提案された解決策：

• プラグインの設定で、API、シークレットキー、URLなどのパラメータが正しいことを確認してください。
• 発信ネットワーク通話でプロキシ接続が必要な場合は、「プロキシを有効にする」が選択されていること、およびプロキシが正しく設定されていることを確認してください。
• 監査セクションの設定に表示されている最終実行時刻付近で発生したエラーについて、ログを確認してください。

ユーザーがtar.gzパッケージでプラグインをアップロードしようとすると 参照ボタンでは、デフォルトではtar.gzファイルは選択できません。

提案する解決策：プラグインパッケージをUIのドロップエリアにドラッグ＆ドロップする。

プラグインの設定を開き、「最終実行日時」の値を古い日時に変更して設定を保存します。「最終実行日時」の値を更新する際は、設定が現在実行されていないことを確認してください。

• Dockerベースのデプロイメントの場合：
  1. コアコンテナのログを取得します このコマンド：
     $ docker-compose logs core | grep WorkerLost
WorkerLostを含むログが 5～6 回程度表示される場合は、問題があることを示しています。 コンテナを再起動します 次のコマンドを実行してください:
     $ ./stop
$ ./start
• Podmanベースのデプロイメントの場合：
  1. コアコンテナのログにアクセスするには、 このコマンド：
     $ podman-compose logs core | grep WorkerLost 。 ログにWorkerLostが5～6回出現する場合、問題が発生していることを示しています。コンテナを再起動します 次のコマンドを実行してください:
     $ ./stop
$ /start

シナリオ：コアログに「プロセス 'ForkPoolWorker-**' pid:552 が 'シグナル 9 (SIGKILL)' で終了しました」というメッセージが表示される場合があります。

影響：コアコンテナが再起動されることが多く、CEによって実行されるタスク（ログの取り込みの遅延など）に遅延が発生する可能性があります。

解決：

• CEは、少なくとも2.2GHzのCPU周波数を持つマシン上でホストされていることを確認してください。
• CPU周波数の基準を満たしていない場合は、基準を満たすマシンに移行してください。
• 既にCPU周波数の基準を満たしている場合は、サポートチームにお問い合わせください。

Cloud Exchange (CE) は、CLS Syslog/Qradar プラグインからネットワーク イベント ログを送信する際に、ログ セクションの「networksessionID」フィールドに警告ログ メッセージを入力します。

Example Warning Log Message in Cloud Exchange UI (under Logging Section):

CLS QRadar [QRadar]([events][network]): フィールド「networkSessionId」のCEFデータ生成中にエラーが発生しました。 エラー: networkSessionId: 整数への変換中にエラーが発生しました。このフィールドは無視されます

Root Cause:

ネットワークイベントにおいて、Cloud ExchangeはnetworkSessionIdフィールドに以下のいずれかを想定しています。

1. 存在しない
2. 有効な数値を二重引用符で囲んで入力してください（例：JSON文字列）。
3. 有効な数値（JSON形式の数値など）を提示してください。

この警告メッセージは、Netskopeテナントの生ログに「networkSessionId」フィールドが利用できない、または予期しない形で存在していることを示しています。このため、このフィールドは該当プラグインのデフォルトマッピングファイルに追加され、Cloud Exchangeはこのフィールドを上記の警告とともに取り込みから除外します。

Troubleshooting Steps/Resolution:

このような場合は、カスタムマッピングを作成し、マッピングファイルからこのフィールドを削除することで、この警告を抑制できます。 これによるCloud Exchangeへの影響はありません。

このフィールドは、デフォルトマッピングファイルのNetwork Eventsで利用可能です。したがって、以下の手順に従ってカスタムマッピングを作成し、「networkSessionId」フィールドを削除して、それぞれのプラグインで使用することができます。

• Cloud Exchangeのユーザーインターフェースにログインしてください。「設定」 Select 。
• サイドパネルで「ログシッパー」 Select 、「マッピング」に移動します。
• 該当するプラグインのデフォルトマッピングファイルを探してください（例：Qradar デフォルトマッピング）。
• デフォルトマッピングファイルのコピーを作成するには、「クローン」アクションをクリックします。
• このカスタムマッピングファイルに名前を付けてください。
• それでは、「イベント」タブを開き、「ネットワークイベント」セクションの「拡張機能」を展開してください。
• 「networkSessionId」フィールドを検索し、マッピングから削除してください。
• マッピングファイルを保存してください。
• 今、戻る矢印キーを使用して、ログ シッパー モジュールに戻ります。
• 「プラグイン」 Select 、該当するプラグイン（Syslog/QRadar）を編集します。
• ドロップダウンリストから選択されているマッピングを変更し、最近作成したカスタムマッピングを選択してください。
• それでは、プラグインの保存をクリックしてください。

しばらくすると、ログセクションに「networkSessionId」フィールドに関連する警告メッセージが表示されなくなるはずです。

参考までに、マッピングの作成方法については、こちらのドキュメントをご覧ください。 Create a Mapping File in Log Shipper

Issue Overview :

Cloud Exchange 内でNetskope provider pluginを設定するユーザーは、 Client Status iteratorに関連するエラーに遭遇する可能性があります。これは、テナントが既に別のユーザーまたは別のCEインスタンスを介して別のモジュール（Netskope CLSまたはNetskope CREなど）によって作成されたクライアントステータスイテレータを持っている場合に発生します。

Error:

TENANT Netskope Tenant (Required) [Support Tenant]: Error while creating iterator with name netskope_ce_cs_iterator. Cannot create Client Status Iterator. One iterator already exists for the Client Status event for your tenant. Delete the existing iterator to continue.

Root Cause:

• 各Netskope tenant supports only one Client Status iterator 。
• プラグイン（Netskope CLSまたはNetskope CRE）が設定されると、Cloud Exchangeは既存のイテレータを確認します。

1. If missing → 新しいイテレータを作成します。
   
2. If already present → 検証が別のユーザーまたは別の CE インスタンスを介してトリガーされた場合、検証は失敗し、エラーが返されます。

この動作はby designです。複数のモジュールは同じイテレータを共有する必要があり、2つ目のイテレータを作成することはできません。

Steps to Troubleshoot:

1. Confirm existing iterator

• エラーメッセージは、テナントに既に同じものが存在することを示しています。
• これは通常、CLS（クライアントステータスが有効になっている場合）またはその他の統合が以前に構成されている場合に発生します。

プラグインを追加しようとした際にログに記録されたCEエラーから、既存のイテレータの名前を確認してください。

API response: {"message":"Only one iterator is allowed per event type. Please use the existing iterator, netskope_ce_cs_iterator_70332c65-aad4xxxxxxxxxxxxxxxxxx, or delete the existing iterator."}

2. Delete the existing iterator

• 既存のイテレータを削除する以下のスクリプト

curl –location –request DELETE '<Tenant_url>/api/v2/events/dataexport/iterator/<iterator_name>' –header 'Authorization: Bearer <token>' 

• 以下を置き換えてください:
  ○ <Tenant_url>
  ○ <iterator_name>: ロギングセクションのエラーログからハイライトされたイテレータ名をコピーします
  ○ <token>

3. Reconfigure plugins in Cloud Exchange

• まずProvider pluginを設定してください。
• 次に、CLS、CRE、その他のモジュールを追加します。
• 同じCEインスタンス内で同じプロバイダープラグインによって作成されたすべてのモジュールは、同じイテレータを共有します。

Resolution:

• イテレータを削除して再構成することで、同一ユーザーが単一のCEインスタンス内で全てのプラグインを正常に構成できるようになります。

Issue Overview

Cloud Exchange > 設定 > 一般タブから診断がトリガーされた場合、ジョブのステータスは「実行中」状態のままになります。 診断ではCloud Exchange展開に関する詳細な情報を収集するため、実行には数分かかりますが、かなりの時間が経過しても「実行中」の状態のままの場合は、以下の手順に従って既存の診断ジョブを停止してください。

Steps to stop the existing diagnose job

1. CE インストール ディレクトリに移動します (HA の場合、診断がトリガーされるノードを使用します)
2. 既に実行中の診断ジョブを確認する
   sudo ps -A | grep diagnose
3. 既存の診断ジョブを強制終了するコマンドを実行します。
   sudo pkill diagnose
4. 古い診断メタデータファイルを削除します。
   • HA展開の場合
     • sudo cd {HA_NFS_DATA_DIRECTORY}
     • sudo rm -f ./diagnose_output/.diagnose_job_*
   • スタンドアロン展開の場合
     • sudo cd {CE installation directory}
     • sudo rm -f ./data/diagnose_output/.diagnose_job_*
5. 診断ジョブの実行を再度トリガーする