Netskope Client の「データセンターピンニング」機能を試してみた

こんにちは、セキュリティチームのHitomiです。

最近、Netskope の公式ドキュメントが頻繁に更新されています。更新内容を追っているなかで、「こんな機能があったんだ」と気づいたのが、今回取り上げるきっかけでした。

この「この機能なんだっけ」シリーズでは、そうやって引っかかった機能をひとつ拾って、公式ドキュメントを読みながら「で、結局どういうときに使えるの？」まで確かめていきます。

初回は Netskope Client のデータセンターピンニング（Data Center Pinning）。接続先の POP を手動で指定できる、という機能です。

当初は IP 許可リストを絞る用途を期待していましたが、検証してみると、むしろ障害時の一時退避や切り分けに向いた機能だと分かりました。

公式仕様と実機検証をもとに、使いどころと運用上の制約を整理します。

0. さきにまとめ

①「POP を手動で固定する」機能は公式に存在します。
nsdiag --pin で国と POP を指定して固定できます。R135.0.0 で GA になりました。特定 POP の障害・劣化時に、健全な別 POP へ一時退避する用途でも使えそうです。

② ただし「IP 許可リストを絞る」用途にはほぼ向きません。
国を選んだあとに ANY または個別 POP を指定できますが、個別 POP へのピン留め中は別 POP にフェイルオーバーしません。加えて最大 24 時間で自動解除され、端末単位のグローバル操作です。

③ 送信元 IP を自社専用にしたいなら、本命は Dedicated Egress IP（DEIP）です。
こちらは別途契約が必要なので、まずは購入元の窓口に契約状況を確認するところからです。

1. そもそも何が困るのか：許可リストが広すぎる問題

Netskope を導入すると、SaaS から見た送信元 IP は端末のグローバル IP ではなく、Netskope NewEdge のデータセンター（POP）の IP になります。

そのため、送信元 IP で制限をかけている SaaS 側には、Netskope の IP レンジを登録する必要があります。公式ドキュメントで公開されているレンジはこちらです。

ポイントは下 2 つの /17 です。それぞれ 32,768 個のアドレスを含みます。しかもドキュメントには「これらのレンジは NewEdge DC の ingress と egress の両方に使われる」と明記されています。

これらは Netskope の共有 IP アドレスプールに属するレンジであり、自社専用の送信元 IP ではありません。そのため、IP アドレスだけを認可条件にした場合、これらのレンジを許可するだけでは、「自社の Netskope テナントからの通信」に限定できません。

「送信元 IP 制限」をアクセス制御の一段目として置いている設計では、制御の粒度がかなり粗くなります。ここを課題としているお客様のお声もよくいただきます。

［出典: NewEdge IP Ranges for Allowlisting］

2. Data Center Pinning とは何か

ここで本題です。公式ドキュメントの定義はこうです。

管理者が Netskope Client の接続先として、国と優先する POP（Point of Presence）を選択できる方式

用途としてドキュメントが挙げているのは「ロケーション固有のキャンペーン」「エンドユーザー向けのターゲティングマーケティング」といった、地域を指定したい場面です。IP 許可リストの絞り込みが主目的として書かれているわけではない、というのは押さえておきたいところです。

公式に整理されている仕様は次のとおり。

［出典: Data Center Pinning In Netskope Client］

「Internet Security Services のみ」という一行は、地味ですが見落とすと痛いポイントです。

NPA（Private Access）の経路はこの機能では固定できません。

3. 有効化と使い方

3-1. テナント側の設定

管理コンソールで Settings > Security Cloud Platform > Netskope Client > Client Configuration > Tunnel Settings を開き、Allow users to select POP（画面のバージョンによっては Allow users to select data center）を有効にします。

同じ画面の Revert to optimal POP after で、自動的にピン留めが解除されて最適 POP に戻るまでの時間を設定します。最小 30 分、最大 24 時間です。

3-2. 端末側の操作

操作は nsdiag コマンドです。Windows / macOS / Linux で同じコマンド体系が使えます。

# 対話モードで国と POP を選ぶ、または直接指定する
nsdiag --pin [country=US|IN|...] [pop=xyz]

# 現在のピン留め状態と残り時間を確認する（実機確認）
nsdiag --pin status

# 手動で解除して自動選択に戻す
nsdiag --unpin

対話モードでは、国を選んだあとに個別 POP または ANY を選択できます。たとえば Japan > ANY とすれば、接続先を日本国内の POP に限定する「疑似的な日本固定」が可能です。（日本にいる場合は、多くのケースで日本の DC に接続されるため、明示的に指定する場面は少なそうです）。

一方、JP-OSA1 や JP-NRT2 などを選ぶと、個別 POP を指定できます。

なお、公式の Command Reference では --pin と --unpin が案内されています。--pin status は今回の実機で状態と残り時間を確認できたコマンドとして記載しています。

nsdiag の配置場所は OS ごとに異なります。

特に難しい作業もなく固定作業は完了……と思いきや、POP がいつまでたっても切り替わらないことに気づきました。そこで追加検証しました（結果は 3-3 へ）。

［出典: Netskope Client Command Reference］

--pin status では、残り時間に加えてトンネルの確立状態（Tunnel Status）も出力されます。切り分けのときに地味に効きます。

いま自分がどの POP に出ているかを確認したいときは、Netskope 経由の状態でブラウザから http://notskope.com/ を開くと、Source IP Address（ロードバランス後の Netskope プロキシの egress IP）と XFF IP Address が表示されます。ピン留めの前後で見比べるのがいちばん早いです。

［出典: Locating Your Netskope NewEdge Data Center］

3-3. 追加検証：ピン留めしても、既存のトンネルは切り替わらなかった

実機（macOS、ピン先 JP-NRT2）で確認できた挙動はこうです。

• nsdiag --pin の実行直後から、--pin status は Pinned POP name: JP-NRT2 と NSTUNNEL_CONNECTED を返す
• ところが Netskope Client の Configuration 画面では、Gateway は JP-OSA2 のまま
• 外部から見た送信元 IP も、ピン留め前に接続していた JP-OSA2 の Gateway と同じ IP レンジのまま

つまり、--pin status の「Pinned」表示は指定が受け付けられた状態を示すだけで、いま実際に接続している POP を保証しません。NRT に固定したつもりでも、実際には大阪の POP から出続けている……という状態が起こり得ます。

私の環境では、ネットワークの切断・再接続を明示的に行ってトンネルを張り直したところ、ピン留めした POP への接続に切り替わりました。既存のトンネルが張られたままの間は、ピン留めが実際の経路に反映されない挙動に見えます。

なお、この挙動について、公式ドキュメントに明示的な記載は見つけられませんでした（2026 年 9 月時点）。あくまで手元の実機確認の結果としてお読みください。

4. ここが惜しい：IP 絞り込み用途で引っかかる制約

さて、ここからが本題の後半です。「POP を固定できるなら許可リストも絞れる」と考えたくなりますが、公式ドキュメントに書かれている制約を並べると、恒久的な IP 制御の手段としてはかなり厳しいことが見えてきます。

① 個別 POP 固定中はフェイルオーバーしない

nsdiag --pin の対話モードでは、国を選んだあとに ANY または個別 POP を選択できます。実機では Japan の選択肢として ANY、JP-OSA2、JP-OSA1、JP-NRT2、JP-NRT3 が表示されました。

Japan > ANY を選べば、特定の 1 つではなく、日本国内の POP を対象にする「疑似的な日本固定」が可能です。一方、JP-OSA1 や JP-NRT2 を選ぶと、個別 POP への固定になります。

通常の GSLB 動作であれば、ある POP が落ちても近隣の POP が受けてくれます。ところがピン留め中はそれが効きません。ドキュメントの記載はこうです。

手動で POP にピン留めされている場合、Netskope Client は別の POP にフェイルオーバーしません。たとえば POP がメンテナンスや障害対応のために停止した場合、ユーザーは手動で unpin して、クラウドが選択する最適な POP に戻す必要があります

個別 POP を指定した場合、同じ都市に別の POP があっても、そちらには逃げてくれません。冗長構成の恩恵をわざわざ捨てている状態になります。

復旧手段が「ユーザーが端末で nsdiag --unpin を実行する」である点も見逃せません。POP 障害の最中に、影響を受けている全端末へその案内を届けて回る・・・というのは手間です。

さらに厄介なのが、この記事の目的である IP 許可リストとの相性です。IP を絞るためにピン留めしているなら、unpin した瞬間に許可リストから外れた IP で出ていくことになります。

「可用性のために解除する」と「IP 制限を通すために固定する」が正面からぶつかる。

② 最大 24 時間で自動的に戻る

Revert to optimal POP after の上限が 24 時間である以上、「この端末は常にこの POP から出る」という状態を設定だけで維持することはできません。一方、各サービス側の IP 許可リストは基本的に恒久的な設定なので、ここで前提がずれます。

③ 端末単位のグローバル操作である

マルチユーザー環境では、ピン留めはユーザー単位ではなくシステム全体に効きます。VDI 環境では、あるユーザーが POP を変更すると、同じ VDI にログイン中の他ユーザーおよび新規ユーザーにも自動的に反映されます。

④ egress IP が POP の国の IP とは限らない

これも効きます。ドキュメントにはこうあります。

テナントで localization zone が有効な場合、POP から出ていく通信の egress IP は、POP の実際の国の IP ではなく、ユーザーの国の IP になることがある

つまり「POP を固定したから egress IP も特定できる」という前提が、テナント設定によっては成立しません。

ドキュメント自身も「egress IP が POP の地理的位置を表さなくなるため、ローカライズされたコンテンツの検証に影響しうる」と注意しています。

［出典: Data Center Pinning In Netskope Client］

⑤ 中国 geo-fence 有効テナントでは挙動が変わる

China geo-fence が有効なテナントでは、nsdiag --pin を実行しても中国固有の POP のみが表示されます。

⑥ そして、POP を固定しても IP は「自社専用」にはならない

仮に POP を固定して、その POP に関連するレンジまで絞り込めたとしても、そのレンジは引き続き Netskope の共有 IP アドレスプールであり、自社専用にはなりません。IP アドレスだけで「自社の Netskope テナントからのアクセス」に限定するという要件は、この機能では満たせません。

［出典: Data Center Pinning In Netskope Client］

Data Center Pinning は「恒久的な IP 制御の手段」ではなく、切り分け・検証・一時的な地域指定のためのツールとして位置づけるのが現実的かと思いました。なお、ピン留め中のユーザーは Devices のエクスポートデータから確認できます。

5. じゃあ、いつ使う機能なのか

制約を並べると「使えない機能」に見えてきますが、そうではありません。制約を逆に読むと、「短時間・意図的に経路を固定したい」場面ではむしろ噛み合う仕様です。

実務で刺さりそうな使い道を 2 つ挙げておきます。

使い道①：特定 POP の障害・劣化が疑われる場合の限定的な手動退避

GSLB は基本的に最適な POP を選んでくれますが、「最適とされている POP が実際には調子が悪い」ことはあります。Trust Portal に告知が出る前の劣化や、特定 POP 経由でだけ発生する事象に当たったときです。

この使い方は、機能がテナントで有効化され、対象ユーザーまたは OU に実行が許可されており、健全な退避先 POP を確認できることが前提です。Netskope 側で全端末を一括して切り替える機能ではなく、個別端末での操作が前提となります。全社的に適用する場合は、端末管理ツールなどから切り替え用のスクリプトを配布・実行する運用が必要です。

これまでこうした場面では、Wi-Fi のオフ・オンで Netskope Client を再接続させ、障害中の POP 以外に割り当てられることを祈る……という「接続先ガチャ」で凌ぐしかありませんでした。どの POP につながるかは GSLB 任せなので、外れを引いたらまた切り替える、という繰り返しです。

Data Center Pinning があれば、このガチャを回さずに、健全な別 POP を狙って nsdiag --pin で一発で退避できます。ここでは「ピン留め中はフェイルオーバーしない」という制約が、「勝手に元の POP へ戻らない」という利点に反転します。

しかも最大 24 時間で自動的に最適 POP へ戻るため、「退避先に固定したまま忘れる」事故も起きにくい。一時退避の道具として見ると、むしろよさそう。

使い道②：検証・切り分けのための経路固定

• 「特定 POP 経由だと事象が再現するか」の切り分け。nsdiag --pin status でトンネル状態と残り時間が見えるので、サポートケースに添える情報も揃えやすいです
• 地域別のコンテンツ配信・ジオ判定の検証。公式ドキュメントが挙げている用途そのものです（ただし localization zone に関する④の注意点は付きます）

最大 24 時間での自動解除や端末単位の操作、個別 POP 指定時にフェイルオーバーしないという仕様も、この使い方であれば許容しやすくなります。

6. 「送信元 IP を自社専用にしたい」の本命

要件が「Netskope 経由の通信を、自社だけの送信元 IP で出したい」なのであれば、本命は Dedicated Egress IP Addresses（DEIP） です。

Netskope 自身のデータシートにも、狙いがはっきり書かれています。

自前のセキュリティ基盤を運用する場合と異なり、SaaS ベースのセキュリティへの移行では共有 IP アドレスプールが提供されることが多い。共有 IP アドレスの悪用を避けるため、Dedicated Egress IP はお客様固有のものとして提供される

NewEdge がカバーする 75 以上のリージョンで実装可能、とされています。

［出典: Netskope Dedicated Egress IP Addresses（データシート）］

7. リリースの経緯

「いつからある機能なのか」がドキュメント上で少し追いにくいので、Golden Release の記載を時系列で整理しておきます。

［出典: Golden Release Updates Between 132.0.0 and 135.0.0］

自テナントで使える状態かどうかは、Client Configuration の Tunnel Settings に Allow users to select POP（画面のバージョンによっては Allow users to select data center）の設定項目が表示されているかで確認できます。

ここに項目が見当たらない場合は、テナントでの有効化がまだの状態です。購入元の窓口までご相談ください。

まとめ

実際に試してみて、Netskope のデータセンターで障害や劣化が発生した際、端末管理ツールからのスクリプト配布などと組み合わせれば、全社的に接続先を切り替える手段として使えそうだと感じました。GSLB 任せの「接続先ガチャ」ではなく、退避先の POP を狙って指定できるのは、緊急時の選択肢として心強いです。

ただし、全員にターミナルを開いて nsdiag を実行してもらう運用は現実的ではありません。実際の落としどころとしては、切り替えと解除のコマンドをスクリプト化し、端末管理ツールなどから対象端末へ配布・実行する形になるのかなと思います。ピン留め後にトンネルの張り直しと接続先の確認も必要になるため、そのあたりまで含めて自動化できると運用しやすそうです。

欲を言えば、Netskope Client のアイコンから退避先 POP を選択し、現在の接続先や残り時間まで確認できるような簡易 UI があると、もっと扱いやすくなりそうです。機能そのものは緊急時や切り分けで役立つだけに、今後は管理者が複数端末へまとめて適用できる仕組みや、ユーザーが迷わず操作できる UI にも期待したいところです。

FAQ

Q1. ピン留めした状態を、ポリシーで恒久的に維持できますか？
公式ドキュメントの範囲では、できません。Revert to optimal POP after の上限が 24 時間で、それを超えると最適 POP に戻ります。管理者が制御できるのは「誰がピンニングを実行できるか」と「最大どれくらい維持できるか」であり、「常にこの POP に固定する」設定ではありません。

Q2. NPA（Private Access）の経路も固定できますか？
Data Center Pinning は Internet Security Services のみが対象です。なお、ユーザー識別情報に基づいて POP のゾーンを選択する Zone Selection Based on User Identity という別機能があり、こちらは NPA トラフィックにも適用されますが、China Elite サブスクリプションを持つテナント向けで、最小クライアントバージョンは 135.0.0 です。用途が限定される点に注意してください。［出典: Zone Selection Based on User Identity］

Q3. 特定の国に限定しつつ、複数の POP を使えますか？
nsdiag --pin の対話モードでは、国を選んだあとに ANY を選択できます。実機では Japan > ANY が選択できたため、接続先を日本国内の POP に限定する「疑似的な日本固定」は可能です。ただし、ANY 選択時に国内 POP 間で自動選択・フェイルオーバーするか、実行時に選ばれた 1 つの POP へ実質的に固定されるかは、公式ドキュメント上で明確な記載を確認できませんでした。
可用性を前提に採用する場合は、事前の実機検証が必要です。

Q4. 検証で使ったあと、解除を忘れると危険ですか？
設定されたタイムアウト（最大 24 時間）の経過、端末の再起動、または nsdiag --unpin の実行で解除されます。そのため放置され続けることは想定しにくい設計ですが、個別 POP へのピン留め中はフェイルオーバーしないため、その間に POP 側で障害があると通信影響が出ます。検証が終わったら nsdiag --unpin を明示的に実行する運用にしておくのが無難です。

Q5. --pin status が Pinned と表示されていれば、もう切り替わっていますか？
実機確認の範囲では、いいえ。--pin status が示すのはピン留めの指定状態と残り時間で、既存トンネルが切り替わったことまでは保証しません。実際の接続先は Client Configuration の Gateway / POP 表示か http://notskope.com/ の Source IP で確認してください（3-3 参照）。

参考リンク（一次情報）

• Data Center Pinning In Netskope Client — Netskope 公式ドキュメント
• Golden Release Updates Between 132.0.0 and 135.0.0 — Netskope 公式リリースノート
• Netskope Client Command Reference — Netskope 公式ドキュメント
• NewEdge IP Ranges for Allowlisting — Netskope 公式ドキュメント
• Locating Your Netskope NewEdge Data Center — Netskope 公式ドキュメント
• Zone Selection Based on User Identity — Netskope 公式ドキュメント
• Netskope Dedicated Egress IP Addresses — Netskope 公式データシート