【SASE実践】[設計] [通信経路] 拠点からSSEへの接続方法の選択肢

今回は実務のディープな領域に踏み込みます。テーマは「拠点からSSE（クラウドプロキシ）への接続方法の選択肢と通信経路の設計」です。

一言に「拠点からSSEにつなぐ」と言っても、実務の設計では以下の2つの通信を明確に区別してアーキテクチャを組む必要があります。

• 【フェーズ1】SSEログイン前の「認証・IdP向け」通信（SP-initiatedのSAML認証など）
• 【フェーズ2】SSEログイン後の「インターネット向け」通信

さらにここに、端末のクライアントエージェントの挙動や製品ごとの制約が複雑に絡み合ってきます。

設計時に迷わないよう、それぞれの選択肢、おすすめの構成、そして実務上の注意点を徹底的に整理していきます。 (※なお、今回は話をシンプルにするため、「リモートから拠点内への通信（ZTNA）」は除外し、拠点発の通信に特化して解説します)

SSEログイン前：IdP（認証）向け通信の選択肢

ユーザーがPCを起動し、SSE（クラウドプロキシ）にログインする前に発生する「IdP（Azure AD/Entra IDやOktaなど）への認証通信」の経路設計です。 ここには3つの選択肢があります。

【選択肢①】SD-WANルータでIdP向け通信をLBO（ローカルブレークアウト）する

拠点のSD-WANルータでIdPのURLを識別し、直接インターネットへ逃がす経路です。

• おすすめ度：★★★★★（イチオシ）
• 理由：無駄な迂回が発生せず、最短経路で認証が成立するため最もシンプルです。
• 注意点：IdP側で「ログイン可能な送信元グローバルIP（GIP）」を制限している場合、各拠点のインターネット回線のGIPをすべてIdP側にホワイトリスト登録する必要が出てきます。
• 実務でのポイント（ログイン後との違い）： ここでLBO対象とするのは、あくまでSSEにログインする前の「認証通信そのもの」だけです。無事にSSEへログインした後は、他のSaaSへアクセスする際のSAML通信（Tokenのやり取りなど）も含めて、すべてSSEのトンネル内でカプセル化されて通信が行われます。そのため、SD-WANルータ側としては「SAML通信」を意識する必要はなく、単なる「SSE向け通信」として扱えばよくなります。

【選択肢②】社内プロキシ経由でIdP向け通信を成立させる

既存の社内プロキシへルーティングし、そこからIdPへ通信させる経路です。

• おすすめ度：★★★☆☆
• 注意点（運用上の盲点）：GPOなどで既存のPACファイルを配布している環境でよくあるトラブルです。SSEのクライアントエージェントは、ログイン後に自身のPACファイルで通信を上書き制御する機能を持っています。 これにより、「ログイン前」と「ログイン後」で参照されるPACファイルが変わるため、ログイン前の挙動が運用の盲点になりがちです。 新入社員の端末やGPOの制御外の端末が「社内からはログインできない（PACが正しくない）のに、自宅（リモート）からだとログインできる」といった、一見不可解なトラブルに陥る例があるため、ログイン前後の設定変更を強く意識した設計が必要です。

【選択肢③】データセンター（DC）等のインターネットGWから通信させる

拠点のデフォルトルートに従い、一度DCなどを経由してIdPへ抜ける経路です。

• おすすめ度：★★★☆☆
• 注意点：SD-WANルータ自体が常時SSEとIPsecトンネルを張っている場合、デフォルトルートもSSEを向いている環境があります。その場合「ログイン前の認証通信そのものを、SSE（未ログイン状態）を通しても成立するよう許可しておく」という一工夫した設計が必要になります。

SSEログイン後：インターネット向け通信の選択肢

無事に認証が終わり、SSEにログインした後の通信経路です。 ここでは「拠点からSSEへIPsecトンネルを張るか、張らないか」で設計が大きく2つに分かれます。これらは一長一短であり、製品特性を見極める必要があります。

【パターンA】拠点からSSEへIPsecトンネルを張る場合（エージェントオフ）

拠点のSD-WANルータからSSEへIPsecを張り、デフォルトルートやクラウドプロキシIP宛てにオーバレイでルーティングします。

• メリット：社内にいる間は端末側のクライアントエージェント機能を「オフ」にできるため、端末側でのカプセル化処理などの負荷を下げ、ルータのハードウェアによるリッチな通信体験を目指せます。
• デメリット（設計の複雑化）：端末が「社内（エージェントオフ＋ルータ経由）」にいる時と「社外（エージェントオン＋リモート）」にいる時で通信方式が変わるため、SSE側で「特定の拠点（ZscalerでいうLocation）」から来た通信なのか、「リモート（RoadWarrior）」から来た通信なのかを厳密に使い分ける必要があり、ポリシー設計が複雑化します。また、仮にエージェントをオンのままにすると、端末とルータの両方でIPヘッダが付与（二重カプセル化）され、MTUサイズが小さくなり転送効率が落ちるリスクがあります。ただし、Zscalerはエージェントからの通信のみで制御・可視化可能なものがあるので、社内でもエージェント（厳密にはトンネル）もオンにすることを推奨しています。

【パターンB】拠点からSSEへIPsecトンネルを張らない場合（エージェント常時オン）

ルータからはIPsecを張らず、社内にいても変わらず端末のクライアントエージェントを活かし、SD-WANルータ側ではSSE向け通信を単にLBO（ローカルブレークアウト）させる方式です。

• メリット：社内でも社外でも端末の挙動（セキュリティポリシー）が一貫するため、管理・運用が非常にシンプルになります。
• デメリット（社内通信の考慮）：エッジでインターネット向け通信を識別して逃がす（LBO）ため、逆に「社内サーバ宛ての通信」については、端末側の設定でSSEのトンネルからバイパスさせて、直接社内網へ向かわせる設定が必須になります。ここを見落とすと、社内リソースへの通信までSSEに吸い込まれてルーティング不能になるため注意が必要です。

見落とし厳禁：エージェントを入れられない端末（サーバ・複合機等）の考慮

パターンB（拠点IPsecなし）を検討する上で忘れてはならないのが「エージェントをインストールできない端末やサーバ」のインターネット通信をどう処理するかという問題です。

社内サーバのアップデート通信、プリンタ・複合機、各種IoTデバイスなど、エージェントレスの通信環境においては、端末単体でSSEのトンネルを張ることができません。これらが安全にSSEを利用してインターネットと通信するためには、ネットワーク（ルーティング）の力でSSEまで通信を導いてあげる必要があります。

つまり、PCなどのOA環境はパターンB（エージェントのみ）で成立したとしても、これらのノンエージェント端末が社内に存在する以上、基本的には「拠点 – SSE間のIPsec接続」をどこかで担保しなければならない、というネットワーク制約が発生します。

製品ソリューションによる「制約」の壁：“社内なのにリモート経路”の罠

このログイン後の設計で最も注意すべきは、採用する製品のアーキテクチャによって「トラフィックの制御思想」が全く異なる点、そしてそれに伴う「予期せぬ迂回ルート（ルーティング競合）」の発生です。

• Zscalerの場合： インターネット向け（ZIA）とリモートアクセス（ZPA）が機能として明確に分離されています。そのため、「拠点（社内）にいる間は、リモートアクセス（ZPA）機能だけを賢くオフにして、インターネット（ZIA）はエージェント経由で通す」といった制御が比較的容易です。
• Prisma SASE等のネットワーク制御型の場合： インターネット向けとリモートアクセス向けのトンネルに明確な機能区分がありません。そのため社内と社外でクライアント側の設定を厳密に使い分けないと、重大なルーティング問題が発生します。

具体的には、「社内（拠点）にいるにもかかわらず、端末側でリモートアクセス用（モバイルユーザー用）のトンネルがそのまま動作してしまう」という事象です。

本来であれば、拠点内や他拠点への通信はSD-WANを経由して最短ルートで簡単に通信できるはずです。しかし、エージェントが掴んだままのトンネルにトラフィックが吸い込まれることで、「一度クラウド上のSSEまでデータを上げ、そこからわざわざ社内に戻ってくる」という、迂回経路を辿ってしまいます。

結果として、社内通信の遅延が悪化するだけでなく、クラウドへのゲートウェイとなる拠点のインターネット回線帯域を無駄に圧迫することになります。

製品によっては、リモートから拠点内へアクセスさせるユーザーを収容するために、アーキテクチャ上の制約として「SD-WANルータ側からSSEへ常時IPsecトンネルを張ること」が必須条件になっているソリューションもあります。

このように、製品が「ネットワーク制御型」である場合は、社内リソースがどこに配置されているか、そして既存のSD-WANの経路とSSEのトンネルがどう競合するかを緻密にロジック立ててシミュレーションし、適用設計を進める必要があります。

まとめ：製品特性と既存リソースの「競合」を見極める

拠点からSSEへの接続設計に「絶対の正解」はありません。

• ログイン前：最短経路の「SD-WANルータでのLBO」が王道だが、GIP制限やログイン前後のPACファイルの切り替わりに注意する。
• ログイン後：運用一貫性を取る（エージェント常時オン）か、パフォーマンスを取る（拠点IPsec＋エージェントオフ）かを選択する。ただし、製品（ZscalerかPrismaか等）のアーキテクチャ上の制約を必ず確認する。

すでに社内に導入されているソリューションや配置されている社内リソース（ADやプロキシ環境）との競合を見落とさないよう、適用設計を進めていきましょう。

設計フェーズで悩まれている方の参考になれば幸いです。

➡【次の記事へ】【SASE実践】[設計] [通信経路]拠点間通信 vs ZTNA：すべてをZTNAに任せるべきか

管理人

自称SASEエンジニアです。 2児の父親をやりながら、日々エンタープライズ向けの次世代ネットワークインフラと格闘しています。一日一投稿を目標に投稿頑張りますので、是非読んでください！