【SASE実践】[設計] [通信経路] PACファイルのバイパスとLBOの整合性を保つ方法

SASE（SD-WAN＋SSE）の導入でよくあるトラブル「特定のアプリだけ通信が遅い」「LBOしたはずなのにプロキシに吸い込まれる」の原因は、端末側のプロキシ制御（PAC）とルーター側のルーティングの不整合にあるケースが多いです。

本記事では、SSEの制御で一般的に使われる「PACファイル」による制御に絞り、SD-WANとどう連動させるべきかの基本方針を解説します。

そもそも制御の「レイヤー」が違う

まずは読者の頭を整理するために、SD-WANとSSEのキャラクターの違いを解説します。

• SSE（プロキシ/DNS）：主にL7（アプリケーション識別、ユーザー認証、コンテンツ検閲）を制御。ブラウザやクライアントが「プロキシ（≒SSE）の宛先」を認識する。
• SD-WAN：主にL3（IPパケット）/ L4（ポート番号）で経路を制御。ルーターが「パケットの宛先」を認識する。
  ※一部DPI（L7）でも識別可。

結論としては、端末が認識する宛先とルーターが認識する宛先を「綺麗に連動（同期）」させることがSASE設計の肝になります。

【ケーススタディ】PACファイルとLBOの不整合が引き起こす「悲劇」

M365（Microsoft 365）などの重い通信を、SSEを経由させずに拠点から直接インターネットへ抜く（LBO：ローカルブレイクアウト）設計を例に、ありがちな失敗パターンを見てみましょう。

① 端末側の挙動（PACファイルの処理）

まず、端末のブラウザやエージェントはPACファイルを参照します。 「M365宛ての通信はプロキシ（SSE）をバイパスする（Return Direct）」という記述があるため、端末は「この通信はプロキシを通さずに、普通のIPパケットとして直接宛先に送ろう」と判断します。ここまでは狙い通りです。

② ルーター側の挙動（SD-WANの落とし穴）

問題は、パケットを受け取った拠点SD-WANルーターの動きです。 端末から「宛先：M365のIPアドレス」の生パケットが届きますが、もしルーター側に「M365宛てなら直接インターネット（LBO）へ出す」という明確なポリシー（スタティックルーティングやアプリケーション識別設定）が同期されていないとどうなるでしょうか？

ルーターは、一般的なSASE拠点の定石通り、「宛先がよく分からない通信は、とりあえずデフォルトルートの向いているSSE（IPsecトンネル）へ転送しよう」（あるいはセンター拠点へのVPNへ迂回させよう）と処理してしまいます。

× 結果として起こる「不整合の悲劇」

• 端末：「SSEを通したくないからバイパスした」
• ルーター：「行き先が分からないからSSE（またはセンター）へ送った」

このボタンの掛け違いにより、バイパスしたはずの通信が結局SSEのトンネルに吸い込まれたり、センター拠点の回線を詰まらせたりするという、意図しない経路への転送が発生します。「設定したはずなのに、なぜかM365が遅い…」というトラブルの正体は、まさにこれです。

ちょっと深掘り（予告）：DNS判定方式の罠 SD-WANルーターがDNS判定方式でLBOする場合、端末が参照するDNSサーバーの配置（拠点LAN内なのか、SD-WAN越しなのか）によって、正常にLBOできないケースがあります。これについては、また別の記事で詳しくまとめます。

「ログイン前・後」で変わる挙動とオンプレ経路の注意点

SSEのクライアントエージェント（Zscaler Client Connectorなど）を利用する場合、実は「SSEにログインする前」と「ログインした後」で、端末に適用されるPACファイル（プロキシ制御）が切り替わる仕様になっていることが一般的です。

この挙動の変化を頭に入れておかないと、「PC起動直後に社内システムに繋がらない」「ログイン画面が出なくてSSEにログインすらできない」という致命的なトラブルを引き起こします。

① 「ログイン前」の挙動と落とし穴

PCを起動した直後、まだユーザーがSSEにログインしていない状態です。

• 端末の動き：一般的には「ログイン前専用のPACファイル」が適用されるか、もしくはプロキシ制御がまだ「オフ」のままで動作します。この時の通信は、すべて生パケット（L3/L4）としてネットワークに送出されます。
• 注意点：この時点で、端末はActive Directory（AD）サーバーにサインインしたり、社内DNSで名前解決をしたり、あるいはSSEのログイン画面を表示するためにインターネット上の認証サーバー（Entra IDなど）にアクセスしたりする必要があります。これらが「ログイン前」の状態で正常にルーティング（既存の閉域網やオンプレ経路経由で）通信できるよう、SD-WANルーター側で受け皿を作っておく必要があります。

② 「ログイン後」の挙動と切り替えの罠

ユーザーが認証を済ませ、SSEに無事ログインした状態です。

• 端末の動き：本番用の「ログイン後PACファイル」に切り替わります。これにより、インターネット宛ての通信は原則としてすべてSSE（IPsecやTLSトンネル）に吸い込まれるようになります。
• 注意点：ここでPACファイルの書き方に不備があると、さっきまで繋がっていた「既存のオンプレミスサーバー（社内リソース）」への通信までSSE側に吸い込まれてしまいます。オンプレ側のプライベートIPアドレスや社内ドメイン（.local など）は、必ずPACファイル内で Return Direct（バイパス）と宣言し、SD-WANルーター側でも適切にオンプレ拠点へルーティング（対向の拠点へVPNや専用線経由で転送）されるように整合性を取らなければなりません。

設計者に求められる視点

設計者は、以下のフェーズや通信要件ごとに「PACファイル（L7）」と「ルーターの経路（L3/L4）」の組み合わせがどう連動するか、全体像を完全に把握しておく必要があります。

「SSEに繋がりさえすればOK」ではなく、ログイン前後どちらの状態であっても、既存のオンプレミス環境と一貫して通信が途切れないこと。これが、既存資産を抱える企業ネットワークにSASEを組み込む際の隠れた最重要ポイントです。

まとめ：SASE設計で迷子にならないための3大原則

端末側（L7/プロキシ）の制御とルーター側（L3/L4/ルーティング）の制御は、放っておくとバラバラに動きます。これらを美しく調和させ、トラブルのないSASE環境を構築するための「3大原則」をまとめました。

1. 例外（バイパス）を作るなら「セットで定義」する M365や特定のVPNなどでSSEをバイパスさせる場合は、必ず「端末（PAC：Return Direct）」と「ルーター（SD-WAN：LBO/専用経路）」の両方に同じポリシーを定義してください。片方だけの設定変更は、通信がデフォルトルート（SSEトンネル等）へ吸い込まれて詰まる原因になります。
2. 「変形された後の宛先IP」を意識する 端末がPACファイルを参照した時点で、パケットの宛先IPは「SSEのIP」や「社内プロキシのIP」に変形されているケースがあります。ルーターのルーティング設計時は、ブラウザの最終目的地ではなく、「ルーターに飛び込んでくる生のパケットの宛先IPが何か」を必ず把握してください。
3. 「ログイン前・後の挙動」を最初から要件定義に入れる PC起動直後のADサインイン、社内DNS、SSEの認証画面へのアクセスなど、「SSEにログインする前の空白の時間」に流れる通信経路を社内LAN（プロキシ必須環境など）とテレワークの両パターンで、初期段階から先回りして設計しておくことが大事故を防ぐ鍵です。

先手を打った設計こそが、最大のトラブルヘッジ

SASEの設計はパズルのようなものです。導入後に「どこか特定の通信だけが異常に遅い」といった原因特定の難しい問題を起こさないためにも、「プロキシ（PAC）とルーティング（SD-WAN）の連動」は、必ず設計の初期フェーズから整合性を確保しておきましょう。

➡【次の記事へ】【SASE実践】[障害シナリオ] SSE（PoP）障害による「全社通信停止」とその回避策

管理人

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