Netskope LogoNetskope Logo
  • セキュリティサービス
  • AIサービス
  • ネットワークサービス
  • 分析サービス
  • 統合
  • getting-started.svg始める
    • サポート
    • コミュニティ
    • Netskope.com
    © 2026 無断転載を禁じます。Netskope 株式会社
    トップページ
    Netskopeクライアント
    Netskope Clientネットワーク構成

    Netskope Clientネットワーク構成

    このトピックでは、Netskope Clientにおけるグローバルサーバー負荷分散（GSLB）に関するさまざまなネットワーク構成要件と、その動作について説明します。

    クライアントのアウトバウンド接続要件

    正常に機能するためには、 Netskope Client以下の表に示すサブネット、ドメイン、ポート、プロトコルに直接アウトバウンド接続できるようにする必要があります。

    – ファイアウォールとプロキシ: これらの接続を復号化せずに許可します。
    – フルトンネルVPN：これらの接続を例外または除外として追加します。
    – スプリットトンネルVPN：これらの接続は含めないでください。
    – 以下の文書には、NG-SWG、クラウドインライン、インラインCASB、クラウドファイアウォール、DNSセキュリティを含む インターネットセキュリティ に関する言及が含まれています。
    – 以下の文書には、Netskope Private Access、NPA、ZTNA Next L7とも呼ばれるPrivate Accessへの言及が含まれています。
    – HTTP/2:元のサーバーが対応している場合はすべてのドメインでHTTP/2を交渉し、そうでなければHTTP 1.1にフォールバックします。 その他のすべてのトラフィックは引き続きHTTP 1.1を利用します。プロトコルの変更はユーザーにとって完全に透過的であり、管理者による設定は一切不要です。コンタクト アカウントでこの機能を有効にするサポート。
    – さらに、 Netskope Client およびGRE/IPSEC、iOSアクセス方式も完全にサポートされています。 

    Netskope Client ファイアウォール許容リストの要件

    Netskope Clientが正しく接続・動作するためには、以下の宛先、ポート、プロトコルがファイアウォール、プロキシ、VPNで許可されている必要があります。 

    Netskope 製品宛先サブネット/ドメインProtocols/Ports目的
    インターネットセキュリティ、

    Private Access    		addon-<tenant>[.region].goskope.comTCP/443設定ファイルのダウンロードとプロキシの動的な検出
    インターネットセキュリティ、

    Private Access    		download-<tenant>[.region].goskope.comTCP/443クライアントパッケージのアップデートをダウンロードしています
    インターネットセキュリティ、

    Private Access    		nsauth-<tenant>[.region].goskope.comTCP/443プライベートアプリ向けIdPベースのクライアント登録と定期的な再認証
    インターネットセキュリティachecker-<tenant>[.region].goskope.comTCP/443クライアント強制（クライアントがインストールされていないユーザーをインストールページにリダイレクトします）
    プライベートアクセスgateway.npa.goskope.comTCP/443Private AccessのためのデータプレーンへのTLS接続Netskope NewEdge
    プライベートアクセス*.npa.goskope.comTCP/443Private Accessのクライアント登録および再登録
    インターネットセキュリティ、

    Private Access    		すべてのNetskope NewEdgeデータ センター サブネットTCP/443データプレーンへのTLS接続Netskope NewEdge
    UDP/443データプレーンへのDTLS接続Netskope NewEdge
    ICMPタイプ8および11、UDP/33434GSLB自動経路制御、PDEM遅延メトリクス収集
    インターネットセキュリティ、

    Private Access,

    Endpoint SD-WAN    		DNSサーバーUDP/53Netskopeサービスへの接続のためのDNS検索
    Endpoint DLPepdlp.gslb.goskope.com、*.epdlp.goskope.com、EPDLP-プロッド。Netskope.ioTCP/443エンドポイント DLP 接続性とポリシー更新
    インターネットセキュリティ、

    Private Access    		enrollment.goskope.com、登録.*.goskope.com、登録.*.govskope.ca、登録.*.govskope.usTCP/443安全な登録接続
    インターネットセキュリティ、

    Private Access    		gateway.gslb.goskope.comTCP/443GSLBレイテンシベースのゲートウェイ選択(近隣データセンター向けのAPI呼び出し)
    GSLBNetskope NewEdge IPスペースICMPタイプ8および11、UDP 33434-33498Netskopeデータセンターへのネットワークパステレメトリ
    Endpoint SD-WAN管理者管理のゲートウェイハブBorderless SD-WANUDP/443エンドポイントからゲートウェイハブへのL3トンネル
    *.googleapis.comTCP/443アプリケーション検出使う ファーストパケット検出
    インターネットセキュリティ、

    Private Access    		dns.google
    8.8.8.8
    8.8.4.4    		TCP/443 インターネットセキュリティとPrivate AccessのためのEDNS地理位置情報に基づくゲートウェイ選択。 これがブロックされるか失敗すると、LDNSの位置情報に基づくゲートウェイ選択が 行われ、接続遅延が増加する可能性があります。
    インターネットセキュリティゲートウェイ-<tenant> [.region].goskope.com

    < tenant>ゲートウェイバックアップ-[.region].goskope.com
    		TCP/443インターネットセキュリティのためのNetskope NewEdgeデータプレーンへのプライマリおよびバックアップTLS接続。
    UDP/443インターネットセキュリティのためのNetskope NewEdgeデータプレーンへのプライマリおよびバックアップDTLS接続。

    パブリッシャーのアウトバウンド接続要件

    このセクションは、プライベートPrivate Access Private Accessパブリッシャーバージョンに適用されます。

    Netskope 製品宛先サブネットとドメインProtocols/Ports目的
    Private Access出版社すべてのNetskope NewEdgeデータ センター サブネットTCP/443Netskope NewEdgeデータ プレーンへの TLS 接続。
    Private Access出版社gateway.gslb.goskope.com
    		TCP/443GSLBのレイテンシに基づくPrivate Accessパブリッシャー向けスティッチャー選択（近くのデータセンターのリストを要求するAPI呼び出し）。
    Private Access出版社DNSサーバーUDP/53Netskopeサービスへの接続のためのDNSルックアップ。これはローカルまたはパブリックのDNSサーバーでも構いませんが、パブリックドメインを解決できる必要があります。
    Private Access出版社*.docker.com
    *.docker.io
    *.ubuntu.com    		TCP/443出版社の最新情報
    Private Access出版社*.ubuntu.comTCP/80出版社の最新情報
    Private Access出版社*.npa.goskope.com

    FQDN の代わりに IP サブネットが必要な場合は、 Netskopeサポート、または営業担当者にお問い合わせください。    		TCP/443パブリッシャー登録

    NewEdgeトラフィック管理ゲートウェイの選択

    NewEdge Traffic Management 2.0 (GSLB) は、レイテンシベースのゲートウェイ選択方法であり、 Google DNS などのサードパーティ サービスに依存するのではなく、 Netskopeがホストする独自の API サービスを使用します。 グローバルサーバー負荷分散（GSLB）は、Netskopeがネットワークの問題を迅速に特定して対処し、パフォーマンス、安定性、および回復力を向上させることで、より優れたユーザーエクスペリエンスを提供します。Netskope Client 、近隣の多数のNewEdgeデータセンターを考慮し、それぞれのデータセンターへのレイテンシ（RTT）を計算し、レイテンシが最も低いデータセンターを選択します。 GSLBに接続できない場合、 Netskope Client以前の拡張DNS（EDNS）およびローカルDNS（LDNS）による位置情報に基づくゲートウェイ選択動作にフォールバックします。

    • GSLBのサービスは、インターネットセキュリティとPrivate Accessにご利用いただけます。
      • NG-SWG: この機能は、プラットフォームバージョン109のリリース以降に作成されたテナントに対して、デフォルトで有効になっています。以前に作成したテナントに対してこの機能を有効にするには、営業担当者またはNetskopeサポートにお問い合わせください。
      • Private Access: GSLBのサービスは、すべてのテナントが利用できます。この機能を有効にするには、営業担当者またはNetskopeサポートにお問い合わせください。
    • GSLB呼び出しが失敗した場合、パブリッシャーとNetskope Client EDNSまたはLDNSにフォールバックします。
    • デフォルトでは、GSLBはレイテンシをテストするために、近隣のデータセンターを10個返します。この値の変更をサポートします。
    • Private Access用：
      • クライアントとパブリッシャーの最小バージョンは109.0.0である必要があります。旧バージョンも引き続きEDNS/LDNSに対応しています。この機能を有効にすると、 Netskope Clientとパブリッシャーの再起動が必要になる場合があります。
        • Netskope Client バージョン 108.0.0 以前のバージョンで GSLB 機能が有効になっている場合、バージョン 109.0.0 にアップデートすると、再起動を必要とせずに GSLB が自動的に有効になります。
        • Netskope Publisherのバージョン108.0.0以前でGSLB機能が有効になっている場合、バージョン110.0.0にアップデートすると、再起動を必要とせずにGSLBが自動的に有効になります。
      • ◇テナントごとに新しいエッジ トラフィック管理ゾーンを構成できます。 コンタクト この機能の設定をサポートします。
      • セッション中は定期的なRTTチェックをサポートしないでください。
      • EDNS/LDNSへのフォールバックは無効にできます。コンタクト この機能の設定をサポートします。

    サポートされているオペレーティングシステム

    GSLBはすべてのオペレーティングシステムでサポートされています。詳細については、 Netskope Clientサポートする OS とプラットフォーム」を参照してください。

    前提条件

    クライアントのバージョンとネットワーク接続要件については、このページの前のセクションにある表を参照してください。ファイアウォールにおけるアウトバウンドアクセスの許可IPアドレス範囲については、サポートポータルを参照してください。

    • FedRAMP High IPは異なり、最新のリストはこちらをご覧ください： https://support.netskope.com/s/article/NewEdge-Consolidated-List-of-IP-Range-for-Allowlisting（サポートアカウントが必要です。）
    • Netskopeテナント経由でクライアントログを収集するには、 「リモートでクライアントデバッグログを収集できません（サポートアカウントが必要です）」を参照してください。

    また、VPNの設定で、これらのIPアドレス範囲がVPNトンネル経由で送信されるように設定されていないことを確認してください。VPNの互換性について詳しくは、 「VPNアプリケーション」をご覧ください。

    GSLBゲートウェイ選定プロセス

    1. Netskope Client NetskopeのAPI（gateway.gslb.goskope.com）に接続します。 HTTPS (tcp/443) を使用して、近くのNetskopeデータ センターのリストを要求します。

    2. Netskopeの API は、エンドポイントの地理位置情報を検索するために API リクエストのパブリック IP を使用します。

    3. NetskopeのAPIは、地理的に近いNetskopeデータセンターのリストを応答として返します。

    4. Netskope Client近隣のNetskopeデータセンターそれぞれへのレイテンシをテストします。

    5. Netskope Clientこれらの遅延測定値を利用して最適なデータセンター（DC）を選択します。 これは通常、レイテンシ（RTT）が最も低いデータセンターですが、場合によっては、レイテンシ特性が類似した近隣のデータセンターが選択されることもあります。

      • NetskopeのAPIへのHTTPS接続がVPN経由で行われる場合、リクエストのパブリックIPが変更され、ユーザーの地理的位置が誤って特定されるため、 Netskope Clientユーザーから遠く離れたNetskopeデータセンターに接続してしまう可能性があります。 。
      • エンドポイントのパブリック IP が位置情報データベースに誤って登録されている場合、 Netskope Clientエンドポイントから遠く離れたNetskopeデータ センターに接続する可能性があります。
      • NetskopeのAPIへのHTTPS接続がブロックされた場合、 Netskope Clientゲートウェイ選択のためのEDNSとLDNSを試みます。

    Netskope Private Accessテナントは、 NewEdge Traffic Managementのインテントベースゾーンを利用できるようになりました。 一部の組織では、インライン（または「データ転送中」）のコンプライアンス要件があり、インライントラフィックの処理を特定の地理的地域に制限しています。現在、 Private Accessテナントは、サポートされているゾーンにトラフィックを制限できます。 詳細については、 「NPAテナントごとにNewEdgeトラフィック管理ゾーンを構成する」を参照してください。

    ゲートウェイ選択動作は EDNS と LDNS を使用します

    NewEdge Traffic Management 1.0 は、位置情報に基づくゲートウェイ選択方法であり、 DNS。 最初に、 Netskope Client EDNSを使用して、以下のゲートウェイ完全修飾ドメイン名（FQDN）のいずれかを解決します。

    • <tenant>gateway-[.リージョン].goskope.com

    • <tenant>gateway-backup-[.リージョン].goskope.com

      EDNS解決が失敗した場合、 Netskope ClientゲートウェイのFQDNを解決するためにLDNSを使用します。

      EDNSゲートウェイ選定プロセス

      EDNSゲートウェイの選択プロセスを理解するには、以下の手順を参照してください。

      1. Netskope ClientはGoogle DNS(dns.google)に接続し、使う DNS over HTTPS (tcp/443)に接続してゲートウェイ<tenant>[.region].goskope.com のIPを要求します。

      2. Google DNS は、HTTPS リクエストを介して DNS のパブリック IP を使用して、エンドポイントの地理位置情報を検索します。

      3. 次に、Google DNS は、gateway-<tenant>[.region].goskope.com をエンドポイントのパブリック IP に地理的に最も近いNetskopeデータ センターに解決します。

      4. Netskope Client提供された IP を使用してNetskopeデータ センターに接続します。

        • DNS over HTTPS接続がVPN経由で行われる場合、リクエストのパブリックIPが変更され、ユーザーの地理的位置が誤って特定されるため、 Netskope Clientユーザーから遠く離れたNetskopeデータセンターに接続してしまう可能性があります。 。
        • エンドポイントのパブリック IP が位置情報データベースに誤って登録されている場合、 Netskope Clientエンドポイントから遠く離れたNetskopeデータ センターに接続する可能性があります。
        • DNS over HTTPS接続がブロックされた場合、 Netskope Client LDNSを使用してgateway-<tenant>[.region].goskope.comを解決しようとします。

    LDNSゲートウェイ選定プロセス

    LDNSゲートウェイの選択プロセスを理解するには、以下の手順を参照してください。

    1. Netskope Client使うエンドポイントの設定済みDNSサーバーを使う標準DNS(udp/53)を使い、ゲートウェイ<tenant>[.region].goskope.com を解決します。

    2. Netskope Client提供された IP を使用してNetskopeデータ センターに接続します。

      DNS サーバーのパブリック IP がエンドポイントから地理的に遠く離れた場所に登録されている場合、 Netskope Clientエンドポイントから遠く離れたNetskopeデータ センターに接続する可能性があります。 たとえば、エンドポイントがカリフォルニア州サンノゼにあるが、バージニア州アッシュバーンにある企業 DNS サーバーを使用するように設定されている場合、エンドポイントはバージニア州アッシュバーン近くのNetskopeデータ センターに接続します。 これにより、 Netskopeを介したすべてのインターネット接続およびPrivate Access接続において、大幅な遅延の増加が生じることになります。

    中国におけるGSLBフォールバック

    バージョン 121.0.7 のリリースにより、中国でNetskopeの POP を使用するテナントは、中国国外でNetskope Client実行しているデバイスは、GSLB に到達できない場合に EDNS にフォールバックし、次に LDNS にフォールバックできます。 同時に、中国のNetskope Clientを備えたデバイスは、これらのユーザーが中国国内のNetskope POP にのみ接続することを保証するために、GSLB のみを使用し続けます。

    これはすべてのテナントのデフォルトの動作ですNetskopeの中国にある POP。

    EDNS/LDNSの検証 

    デバッグ中にログから国コードを確認できます。

    • 場所が中国にある場合：

      2024/09/25 17:33:58.421 stAgentSvc p1d14 t1ed8 info GatewaySelection.cpp:139 gslb [NSClient] Pops fetched begin rtt_protocol:tcp country:CN

    • 場所が中国国外の場合：

      2024/09/25 09:09:52.105766 stAgentNE p14257 t15367 info GatewaySelection.cpp:139 gslb [NSClient] Pops fetched begin rtt_protocol:http country:US

    プロキシ環境ではないNetskope Client

    クライアントがプロキシ環境ではない場所にインストールされている場合に、クラウドアプリのトラフィックがどのように傍受され、トンネルを通して送信されるかを示すパケットフローの詳細を以下に示します。

    1. クライアントは、クライアントとNetskopeゲートウェイ間のSSLトンネルを確立します。
    2. ブラウザ/アプリは、マネージドクラウドサービス（例：Box.com ）に対してDNSリクエストを送信します。
    3. Browser/App receives a DNS response (For example: 74.112.184.73).
    4. クライアントドライバはDNS応答をキャプチャし、ドメインとIPのマップを作成します（例：クラウドアプリドメインの場合、Box.com = 74.112.184.73 ）。
    5. Browser/App sends packets to Box.com (For example: DST IP 74.112.184.73).
    6. クライアントトンネル ボックストラフィック（例：宛先IP 74.112.184.73 ）SSLトンネル経由で。

    明示的なプロキシ環境におけるNetskope Client

    クライアントが明示的なプロキシ環境にインストールされている場合に、クラウドアプリのトラフィックがどのように傍受され、トンネル経由で送信されるかを示すパケットフローの詳細を以下に示します。

    1. クライアントは、クライアントとNetskopeゲートウェイ間のSSLトンネルを確立します。クライアントはまず、デフォルトゲートウェイを介して直接接続して SSL トンネルを確立します。 これがブロックされた場合、PAC（プロキシ自動構成）ファイル、WPAD（ウェブプロキシ自動検出プロトコル）、手動構成などのシステムプロキシ設定を探します。 クライアントは プロキシ設定を行い、HTTP Connect経由でNetskopeゲートウェイに接続します。

      プロキシがSSL復号化用に設定されている場合は、NetskopeゲートウェイをSSL許可リストに追加する必要があります。お使いの環境が ファイアウォールまたはプロキシを使用している場合は、バックアップゲートウェイのURLをプライマリゲートウェイのURLと同じ方法で処理するようにしてください。 バックアップゲートウェイのURLは、プライマリURLの末尾にgateway-backupが付加されます。

    2. ブラウザまたはネイティブアプリはプロキシ設定（PACファイル、明示的なプロキシ設定）を読み込み、例えばep.customer.comのような明示的なプロキシサーバーへの接続を開きます。

    3. クライアントは接続の初期ヘッダーを解析する。

    4. 初期ヘッダーが接続を示している場合：

      • クラウドモード（SaaSアプリ）：最初のヘッダーには、SaaSアプリケーションのホスト名が表示されます。ホスト名が管理対象SaaSアプリケーションの例外設定に含まれていない場合、クライアントはトラフィックをローカルプロキシサーバーに迂回します。

      • ウェブおよびすべてのトラフィック モード: 最初のヘッダーはウェブ アプリケーションのホスト名を示します。 ホスト名が例外の一部である場合、クライアントはトラフィックをローカルプロキシサーバーに迂回します。それ以外の場合は、トラフィックはNetskopeゲートウェイにトンネル接続されます。

    5. 初期ヘッダーがSaaSアプリのHTTPSアクセスを示していない場合、 Netskope Clientトラフィックをバイパスし、ペイロード全体を明示的なプロキシサーバーに転送します。 例えば、ep.customer.com。

    Netskope Clientログメッセージ（オンプレミスプロキシ使用時）

    Steering traffic flow and Log messageオンプレミスプロキシを使用する場合、Netskope Client は HTTP CONNECT リクエストを監視します。これらのリクエストに含まれるドメイン名を、管理対象ドメインリストと照合します。名前が一致する場合、TCP SYNパケットを再構築してNetskopeトンネル経由で送信し、同時にオンプレミスプロキシにTCP RSTを送信して、その接続を制御します。NetskopeプロキシとのTCP 3ウェイハンドシェイクの後、HTTP CONNECTリクエストが送信され、Netskopeプロキシとのフローが継続されます。Netskope Clientがメッセージをログに記録する際、TCPフローはオンプレミスプロキシの宛先IPアドレスで行われるため、宛先IPアドレスはオンプレミスプロキシとして表示され、ドメイン名は管理対象ドメインとして表示されます。

    オンプレミスのプロキシIPアドレスが10.10.10.11、プロキシポートが8080、管理対象ドメインがwww.box.comであると仮定すると、以下のようなログ行が表示されます。

    2021/07/18 17:16:11.282 stAgentSvc pfbc t296c 4 tunnel.cpp:618 nsTunnel TLS [sessId 1]
Tunneling flow from addr: 192.168.13.40:49614, 
process: chrome.exe to host: www.box.com,addr: 10.10.10.11:8080
    このトピックでは
    • Netskope Clientネットワーク構成