一般的なトラブルシューティングでは、クライアント、パブリッシャー、プライベートアプリ、およびポリシーを確認します。
Netskopeクライアント
Netskope Client NPAに接続されていますか？
- システムトレイにあるNetskope Clientアイコンを右クリックします。 Private Access有効になっていると表示されるはずです。
For Windows
For Mac
- Private Accessが無効になっていると表示される場合は、テナントのステアリング構成設定で「すべてのプライベートアプリをステアリングする」オプションが有効になっていることを確認してください。 Settings > Security Cloud Platform > Steering Configurationへ移動してください。
ヒント
デフォルトのテナント構成のみの場合は、右上隅のEditをクリックしてください。
複数のステアリング構成がある場合は、 NPAに使用するステアリング構成のメニュー アイコンをクリックします。
すべてのプライベート アプリ セグメントが トラフィックを誘導し、有効になっていることを確認してください。
- 完了したら、 Saveをクリックしてください。
Netskope Client NPAに一度も接続したことがありませんか？
クライアントが有効にならない場合、 Netskope Client NPA有効にするために、 ネットワーク接続がアクティブになる前に、最も近いNetskope POPに登録/登録しようとしている可能性があります。 現在、 Netskope Clientネットワークの状態を再度確認しません。
回避策: システムタスクバー (Windows) またはメ ブルバー (Mac) にNetskope Clientアイコンが表示されている場合は、 Netskope Client無効にしてから再度有効にして、接続されていることを確認してください。
貴社はネットワーク上で第三者によるSSL/TLS検査を実施していますか？
はいの場合、 NPAを考慮に入れてください。 Netskope GatewayとStitcherに接続するための独自のドメイン名。 クライアントが正常に接続するためには、以下のURLを迂回する必要があります。
Netskope Publisherとプライベートアプリ
ユーザー/組織単位がPrivate Accessを許可されているかどうかを確認するにはどうすればよいですか？
nsdebuglog.log ファイルを開き、 「enroll」という単語を検索します。ユーザーの登録手続きがうまくいかない理由について、より詳しい情報が表示される場合があります。
Netskope UIのパブリッシャーヘルスチェックで、アプリに接続できることが表示されていますか？
プライベートアプリがTCP/UDPポートのリストで定義されている場合、接続性の確認は最初のポートのみで行われます。このステータスは、定義されたすべてのポートにアクセス可能であることに依存しません。これは、パブリッシャーが定義されたすべてのポートに正常に接続できるという誤った認識につながる可能性があります。
ルーティング/ポリシーの観点から、パブリッシャーは定義されたプライベートアプリにアクセスできますか？
- パブリッシャーにSSH接続します（ユーザー名は
ubuntuです）。 - メニューを終了するには、オプション3を選択してください。
suを入力してください。これによりroot権限でログインできます。apt-get install traceroute -yを入力してください。- プライベートアプリケーションのローカルIPアドレス/ドメイン名へのtracerouteを試してください。
パブリッシャーは、定義されたすべてのポートで、定義されたプライベートアプリにアクセスできますか？
- パブリッシャーにSSH接続します。
suを入力してください。これによりroot権限でログインできます。apt-get install telnet -yを入力してください。- 試す プライベートアプリケーションのローカルIPアドレス/ドメイン名にtelnetでアクセスする:
telnet <hostname><port>.
接続できれば、すべて順調です。そうでない場合は、ネットワークまたはホストのセキュリティポリシーによって、指定されたポートでパブリッシャーがサーバーと通信することがブロックされている可能性があります。
OSXのオープンファイルディスクリプタの制限を増やす必要はありますか？
OS X のファイルディスクリプタの制限値（デフォルト）は 256 と低く、ネットワークアクセスが多い場合には問題となる。まず現在の制限を確認し、次にその制限を緩和するためのカスタム制限を作成してください。
システムのデフォルト/現在の制限値を確認してください
システムのソフトリミットとハードリミットを調べるには、以下のコマンドを実行してください。
- ソフトリミットを見つけるには、次のコマンドを実行します: ulimit -Sn サンプル出力: % ulimit -Sn 256
- ハードリミットを確認するには、次のコマンドを実行します: ulimit -Hn 出力例: % ulimit -Hn unlimited
カスタム制限を設定する
- 実行: sudo touch /Library/LaunchDaemons/limit.maxfiles.plist
- お好みのファイルエディタでファイルを開き、以下のデータをファイルの内容として貼り付けてください。<?xml version=”1.0″encoding=”UTF-8″?> <!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”> <plist version=”1.0″><dict> <key>Label</key> <string>limit.maxfiles</string> <key>ProgramArguments</key> <array> <string>launchctl</string> <string>limit</string> <string>maxfiles</string> <string>25600</string> <string>100000</string> </array> <key>RunAtLoad</key> <true/> <key>ServiceIPC</key> <false/> </dict> </plist>
- 制限値を希望の値に置き換えることができます。ハードリミットは、システムがサポートする値（
ulimit -Hnの出力）よりも小さくする必要があります。カスタム値を設定する場合、OSXでは現在、ハードリミットをunlimitedに設定することができないため、高い値を設定する必要があります。上記の例では、ソフトリミットは25600、ハードリミットは100000です。 - ファイルを保存してシステムを再起動してください。
- システムを再起動後、以下のコマンドを実行して現在の制限値を確認してください。ソフトリミットを確認するには、ulimit -Sn を実行します。出力例: % ulimit -Sn 256 ハードリミットを確認するには、ulimit -Hn を実行します。出力例: % ulimit -Hn 100000。
プライベートアプリケーションには、発行者のIPアドレスからのアクセスをブロックするセキュリティグループ/ACLが設定されていますか？
これは、パブリッシャーがAWSのようなIaaS環境内にデプロイされている場合に発生します。ホストのセキュリティグループを確認してください。定義されたプライベートアプリケーションへのすべてのトラフィックは、ローカルネットワーク上ではクライアントのIPアドレスから発信されたものとして認識されます。
リアルタイム保護ポリシー
ユーザーがプライベートアプリにアクセスするためのリアルタイム保護ポリシーはありますか？
Netskope UIでPolicies > Real-time Protectionに移動し、ユーザー/OUがプライベートアプリケーションに対してユーザーを承認していることを確認します。
先ほど適用したリアルタイムポリシーは有効になりましたか？
テキストエディタでnpadebuglog.logファイルを開きます。Netskopeテナント内のプライベートアプリで定義されているプライベートアプリの名前を検索してください。
Windowsの場合： C:UsersPublicnetSkopenpadebuglog.log
macOSの場合： /Library/Logs/Netskope/npadebuglog.log
このファイルにプライベートアプリ名が記載されていない場合、プライベートアプリに接続することはできません。これは、ユーザーがこのプライベートアプリの使用を許可されていないことが原因である可能性があります（リアルタイム保護ポリシーを確認してください）。
Tenant UI
NPAブラウザアクセスを使用してカスタムURLのプライベートアプリ証明書を設定する際に、クロス署名されたルート証明書はサポートされていますか？
Netskopeは自己署名ルート証明書をサポートしています。証明書チェーンファイルでは、クロス署名されたルート証明書はサポートされていません。クロス署名されたルート証明書が の場合、 「ルート証明書が見つかりませんでした」というエラーが表示されます。
デフォルトでは、Let's 暗号化 CA は、 DST ルート CA X3によって相互署名されたISRG ルート X1を使用する証明書チェーンを作成します。 これがエラーの原因です。
Workaround
証明書チェーンの一番下にあるはずの、 ISRG Root X1クロス署名証明書を削除してください。次に、 こちら からダウンロードできる ISRG Root X1 自己署名証明書を追加します。