はじめに
こんにちは、ネクストモード株式会社のiwaです。
2026年8月にネクストモードに入社し、Netskopeを含め、ゼロトラストに関するSaaS製品をメインで触っています。
Netskope Clientを配って運用が始まると、次に「この機器にはClientが入らない」という話が出てきます。
Clientを入れられないけど、
通信を可視化して制御したい機器やサーバーはどうすればいいのか。
そこが自分の疑問でした。
今回は、そうした機器やサーバーがインターネットへ出ていく通信を、ネットワーク側からNetskopeへ送って管理する方法（IPSec Sites）を整理します。ライセンスと帯域は第2回で扱います。IPSecはパブリッククラウド上の通信も対象にできるため、第3回・第4回では実際にAWS環境で構成と検証を行います。
結論
この記事の結論
- 端末を管理する基本は、Netskope Clientです。証明書の配布や社外での利用まで守れるので、公式も導入を勧めています。[4]
一方、Clientを入れられない機器やサーバーの通信も、企業が管理するネットワークの出口からIPSecでまとめて送れば、Netskopeで管理できます。出口は拠点だけでなく、データセンターやAWSなどのパブリッククラウドにもあります。[1][15]- ただし、その出口を通らない通信は対象になりません。たとえば、自宅から直接インターネットへ出る個人PCなどです。IPSecはClientの代わりではなく、通信を届ける経路の1つです。[15]
- IPSecで届いた通信は、WebならURLやカテゴリ、Web以外なら宛先IPやポートで制御できます。誰の通信かを見分けるには、ClientかSAML認証が別に要ります。
- 自社で使えるかは、どの機器が、どこへ、企業が管理するどの出口を通って通信するかの3点で判断できます。
Netskopeへ通信を届ける方法はいくつかあり、そのうち企業が管理するネットワークの出口からまとめて送るのがIPSecです。
📖 参考：
[4] User Identity Methods for IPSec and GRE Tunnels
[15] Steering Traffic through Netskope Security Service Edge（Netskope公式資料）
Clientを入れられない機器の通信は、ネットワークの出口からまとめて送る
IPSecは、機器ごとではなく、ネットワークの出口ごとに通信をNetskopeへ送る方法です。[1]
出口とは、対象の通信がインターネットへ出るときに通るルーターやファイアウォールのことです。そこから、Netskopeの接続拠点であるPoPへトンネルを張ります。管理画面では、この接続設定を IPSec Site と呼びます。[5]
出口は、オフィスや工場だけではありません。公式資料では、トンネルの送信元として、ルーター、ファイアウォール、SD-WAN機器のほか、AWS・Azure・GCPなどのパブリッククラウドも挙げられています。[15]
同じ資料には、トンネルを検討する場面の例として次の3つがあります。[15]
- ユーザーのログインを前提とせずに動くサーバー
- 企業のネットワークにつながる、管理していない端末（Guest Wi-Fiなど）
- Clientに対応していない機器（IoT機器、スマートデバイスなど）
IPSec Siteの設定にも、トンネルの通信の種類として User／IoT／Mixed／Machine／Guest Wifi を選ぶ項目があります。[1]
一方で、企業が管理する出口を通らない通信は、IPSecでは届きません。自宅や外出先から直接インターネットへ出る個人PCなどがその例で、公式資料でも別の方式を案内しています。[15]
「Clientを入れられるか」と合わせて、「その通信の経路を企業側で制御できるか」も確認します。
出口の機器には、次の条件があります。[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トンネルへ送られない構成なら対象外です。
AWSなどクラウド上のサーバーも、考え方は同じです。そのサーバーがインターネットへ出る経路を、トンネルへ向けられるかが分かれ目です。この構成は、第3回・第4回のAWS検証で確認します。
判断の分かれ目は、機器名ではなく、その機器のどの操作が、どの経路を通って、どこへ通信するかです。
おわりに
今回整理して分かったのは、IPSec Sitesは「拠点をつなぐための仕組み」だけではなく、Netskope Clientだけでは届けられない通信を、企業が管理するネットワークの出口からNetskopeへ届ける方法の1つだということです。拠点だけでなく、サーバーネットワーク、Guest Wi-Fi、データセンター、パブリッククラウドも出口の候補になります。
一方で、IPSecはClientの完全な代わりではありません。トンネルを張るだけでは、利用者の識別やHTTPSの復号まで完了しません。経路、識別、復号を分けて考えることが、Clientを入れられない機器を管理するポイントです。
自社で検討するなら、まず機器やサーバーを1つ選び、機器名／通信先／プロトコル・ポート／通る出口／管理したいことをメモしてみてください。分からない項目は空欄のまま、ネットワーク担当者と確認を進めます。
次回
第2回では、IPSecを利用するために必要なライセンス、帯域、容量評価を整理します。
自社の構成で判断がつかない場合は、弊社でもNetskopeの導入支援を行っていますので、お問い合わせください。
本記事の公式ドキュメントの確認日は2026年10月2日です。仕様・画面は変更される可能性があるため、構成時には最新の公式資料をご確認ください。
補足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]
自宅や外出先のPCも、IPSecで管理できますか？
IPSecだけでは管理できません。IPSecが届けるのは、企業が管理するネットワークの出口を通る通信です。自宅や外出先から直接インターネットへ出る通信は、その出口を通りません。[15]
会社の端末ならNetskope Clientを使います。Clientを入れられない個人端末については、公式資料でIPSec以外の方式が案内されています。[15]
AWSなどクラウド上のサーバーも対象にできますか？
対象にできます。公式資料では、トンネルの送信元として、AWS・Azure・GCPなどのパブリッククラウドも挙げられています。[15]人がログインしないサーバーの通信も、トンネルを検討する例に含まれています。[15]
利用者の識別は、オンプレミスの場合と同じ考え方です。ブラウザでログインしない通信は、送信元IPを指定してSAML認証の対象から外します。AWSでの構成は第3回、通信の確認は第4回で扱います。
復号しない通信にも、ポリシーは効きますか？
限られた範囲で効きます。公式には、「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回で整理します。