はじめに
こんにちは、ネクストモード株式会社のiwaです。
2026年8月にネクストモードに入社し、Netskopeを含め、ゼロトラストに関するSaaS製品をメインで触っています。
Netskope Clientを配って運用が始まると、次に「この機器にはClientが入らない」という話が出てきます。
Clientを入れられないけど、
通信を可視化して制御したい機器はどうすればいいのか。
そこが自分の疑問でした。
今回は、そうした機器のインターネットへ出ていく通信を、Netskopeで管理する方法を整理します。ライセンスと帯域は第2回、AWSでの構成と構築は第3回・第4回で扱います。
結論
この記事の結論
Netskopeへ通信を届ける方法はいくつかあり、そのうち拠点のネットワーク機器からまとめて送るのがIPSecです。
Clientを入れられない機器は、拠点の出口からまとめて送る
IPSecは、機器ごとではなく、拠点の出口ごとに通信をNetskopeへ送る方法です。[1]
出口は、対象の通信が拠点からインターネットへ出るときに通るルーターやファイアウォールで、そこからNetskopeの接続拠点であるPoPへトンネルを張ります。管理画面では、この接続設定を IPSec Site と呼びます。[5]
出口の機器には、次の条件があります。[1]
- IKEv2に対応していること（NetskopeがサポートするのはIKEv2だけ）
- NAT-Tに対応していること
- 事前共有鍵（PSK）で認証できること
- 公式の対応表にある暗号方式・DHグループを使えること
相手の死活を確かめるDPDとキープアライブの有効化も、公式が推奨しています。[1] トンネルは、異なる2つ以上のPoPへ張ることが必須です。予備のトンネルへ切り替わるフェイルオーバーを設定し、その切り替えを定期的に試験することも求められています。切り替えは出口の機器の側で起き、Netskopeからは見えないためです。[1]
拠点のすべての通信をトンネルへ流す必要はありません。公式には、ポリシーベースルーティング（PBR）でHTTP/HTTPS（80番・443番）の通信だけをトンネルへ向ける例があります。[1]どこまで選り分けられるかは、出口の機器の経路制御の機能（PBRなど）で決まります。
ここで、通信を「どこへ送るか」と、Netskopeへ到達した後に「どう処理するか」は分けて考えます。IPSec配下では、拠点側のルーティングが通信をトンネルへ送るかを決めます。Netskope Cloudへ到達した後は、例外設定やポリシーに従って処理されます。具体的な挙動は第4回で確認します。
IPSecで届いた通信で、何が見えるのか
見える範囲は、Webの通信かそれ以外か、そしてユーザーを識別するかどうかで変わります。
IPSecは、通信を届けるだけです。届いた通信を管理するのは、Secure Web GatewayやCloud Firewallの機能で、IPSecを使うにもどちらかのライセンスが必要です。[1]
Clientなしで、誰の通信かを見分けるには
IPSec／GRE経由の通信をユーザー単位で識別するには、Netskope Clientによる識別かSAML認証を組み合わせます。
Clientを導入していなくても、ブラウザでIdPのログイン画面を操作できる端末なら、IPSec／GRE経由のSAML認証で利用者を識別できます。[4]利用者がブラウザで外部のWebサイトを開くと、Netskopeの認証プロキシを経てIdPのログイン画面に移り、ログインすると目的のサイトが表示されます。[12]既定では、認証した利用者と端末のIPアドレスを対応付けます。[13]
一方、サーバーやCLIのみの機器など、人がブラウザでログインしない通信はSAML認証を完了できません。そのような通信には、送信元IPを指定して認証対象から外す設定があります。公式は、ゲスト用Wi-Fiやサーバーのサブネットを例に挙げています。[14]対象から外した通信は利用者を特定できませんが、Webの通信には「Unknown」を対象にしたカテゴリのポリシーを設定できます。[2]
HTTPSの中身を見るには、証明書の信頼が要る
HTTPSの中身を検査するには、機器やアプリがNetskopeのCA証明書を信頼している必要があります。
図2のとおり、IPSecが暗号化するのは出口とPoPの間で、HTTPSの中身を見るTLS復号とは別の仕組みです。Clientのない機器へルートCA証明書を配布する手順は、公式に用意されています。[4]
証明書ピンニングを使うアプリの中には、CA証明書を配っても復号できないものがあります。[6]Clientでは、こうしたアプリを復号せずに通すよう、ステアリングの設定で指定できます。IPSec／GREでは、通信がブラウザからかアプリからかを見分けられないため、この指定は使えません。[10]代わりに、SSL復号をしないポリシーで、対象のドメインやカテゴリを指定します。[10]第4回では、AWS検証環境で確認した通信経路とイベントを紹介します。
📖 参考：
[2] Create a Real-time Protection Policy for Web Categories
[4] User Identity Methods for IPSec and GRE Tunnels
[6] Certificate Pinned Applications
[10] Netskope公式 - Tips and FAQs
[12] Test SSO via the IPSec or GRE Tunnel
自社の候補は、機器・通信先・出口の3点で見つける
機器・通信先・出口の3点が分かれば、その機器をIPSecの検討対象にできるかを判断できます。
複合機で考えると、クラウドへのスキャン送信やファームウェアの取得は、出口を通るインターネット向けの通信なので検討対象になります。機器内で完結するコピーは対象外です。社内ファイルサーバーへの保存も、通信が拠点内で完結し、IPSecトンネルへ送られない構成なら対象外です。
判断の分かれ目は、機器名ではなく、その機器のどの操作が、どこへ通信するかです。
おわりに
今回整理して分かったのは、IPSecはNetskope Clientの完全な代わりではなく、拠点の通信をNetskopeへ届ける方法だということです。トンネルを張るだけでは、利用者の識別やHTTPSの復号まで完了しません。経路、識別、復号を分けて考えることが、Clientを入れられない機器を管理するポイントです。
自社で検討するなら、まず機器を1つ選び、機器名／通信先／プロトコル・ポート／通る出口／管理したいことをメモしてみてください。分からない項目は空欄のまま、ネットワーク担当者と確認を進めます。
次回
第2回では、IPSecを利用するために必要なライセンス、帯域、容量評価を整理します。
自社の構成で判断がつかない場合は、弊社でもNetskopeの導入支援を行っていますので、お問い合わせください。
本記事の公式ドキュメントの確認日は2026年9月27日です。仕様・画面は変更される可能性があるため、構成時には最新の公式資料をご確認ください。
補足Q&A：設定や調べ方をもう少し詳しく
ここからは、調べる中で自分が気になった点をQ&Aで整理します。気になるところだけ開いてください。
Clientとの関係
IPSecとClientは、同じ端末で併用できますか？
できます。ClientはIPSec／GREのトンネルを検出すると、自分での転送を止めます。そのあとの通信はトンネルで送られます。[10]
ユーザー情報をClientから渡すには、Clientの設定で「Enable device classification and client-based end user notifications when the Client is not tunneling traffic」を有効にします。[10]これで、通信はIPSecで送り、ユーザー名と利用者への通知はClientが受け持つ構成になります。[4]
ブラウザ以外のアプリの通信も、SAML認証で利用者を見分けられますか？
方式によります。既定の方式（IP surrogate）は、認証した利用者を端末のIPアドレスと対応付けます。[13]複数の利用者が同じIPに見える環境で使うcookieの方式では、cookieのリダイレクトに対応しないデスクトップアプリは、ユーザー情報を取得できない場合があります。[13]
📖 参考：
LinuxのCLIのように、ブラウザを使わない機器はSAML認証できますか？
公式の認証手順は、ブラウザでWebサイトを開くところから始まります。[12]人がブラウザでログインしない機器は、送信元IPを指定して認証の対象から外す設定で扱います。公式の例にも、サーバーのサブネットが挙がっています。[14]
つなぎ方
図1にあるGREとは、何が違うのですか？
GREは通信自体を暗号化しませんが、IPSecは通信を暗号化します。インターネット経由で拠点の通信を送る今回の用途では、特別な理由がなければIPSecを選びます。帯域や構成条件は異なるため、採用前に公式Docsと契約条件を確認します。
出口の機器には、何が必要ですか？
IKEv2とNAT-Tへの対応が前提です。[1]そのうえで、暗号化方式などトンネルの条件を、機器の資料とNetskopeの資料で照合します。対象の通信だけをトンネルへ向けるなら、PBRなどの経路設定ができるかも見ます。
📖 参考：
トンネルの設定は、Netskope側と拠点側のどちらで行いますか？
両方です。Netskope側にIPSec Siteを作り、拠点側のルーターやファイアウォールに、接続相手・認証・暗号化などの条件を設定します。[1][5]それとは別に、対象の通信をそのトンネルへ向ける経路も設定します。
管理できる範囲
来訪者のゲスト端末も対象にできますか？
対象にできます。ただし、Netskope CA証明書を配布していないゲスト端末のHTTPS通信は、証明書エラーを避けるため、復号対象から除外する構成を検討します。
ゲスト用Wi-Fiの通信をIPSecトンネルへ送り、ゲスト用ネットワークは送信元IPでSAML認証の対象から外します。[14]そのうえで、Unknownを対象にしたカテゴリのポリシーで、アクセスできる範囲を決めます。[2]復号しない通信も、限られた情報でポリシーと照合されます。[7]
復号しない通信にも、ポリシーは効きますか？
限られた範囲で効きます。公式には、「Do Not Decrypt」に一致した通信を、限られた情報でReal-time Protectionポリシーと照合する説明があります。[7]中身を見ないので、中身にもとづく検査はできません。
📖 参考：
[7] SSL Decryption
契約
IPSec Siteを使うのに、何の契約が要りますか？
Secure Web GatewayまたはCloud Firewallのライセンスが必要です。500MbpsはHigh-Capacity Tunnelの追加ライセンスは不要ですが、事前の容量評価が必要です。1Gbps以上を利用する場合は、High-Capacity Tunnelのライセンスも必要です。契約と帯域は第2回で整理します。