2026.06.19 2026.06.20

【SASE実践】[障害シナリオ] ZTNAとSD-WANの経路競合とそれを防ぐ「ロケーション認識」

buffoon

以前のいくつかの記事でも、SASEを導入するにあたって「社内環境と社外環境の使い分け」がいかに重要かという点について触れてきました。

今回はそこからさらに一歩踏み込み、現場のインフラエンジニアが最も頭を悩ませる実務レベルの課題――「ZTNAエージェントとSD-WANルーターの経路競合」のメカニズムと、その解決策である「ロケーション認識」の具体的な設計テクニックについて、どこよりも詳しく深掘りして解説します。

現場で起きる悲劇：なぜオフィスにいるのに通信が「超遠回り」するのか？

この障害は、「昨日まで在宅ワークをしていて、今日そのままオフィスに出社したユーザー」のPCで高確率で発生します。

ユーザーから「出社した途端、社内システムへのアクセスだけが激重になった」「社内アプリのセッションが頻繁に切れる」という申告があった場合、バックエンドのネットワークでは以下のような「ルートの奪い合い」が起きています。

正常な在宅ワーク時のルート

在宅環境では、PCにインストールされたSSE接続エージェント（Zscaler Client Connectorなど）が、社内システム宛て（例：10.0.0.0/8）の通信をキャッチし、安全な暗号化トンネルでSSEクラウドへ送ります。

[端末] → [インターネット] → [SSEクラウド] → [ZTNAコネクタ] → [社内システム]

オフィス出社時に起きる「Uターン現象」

本来、オフィスに出社している状態であれば、足元のローカルネットワークから、オフィスのSD-WANルーターの拠点間VPNを経由して、社内システムへ直接アクセスするのが最短ルートです。

しかし、端末のエージェントが「社内宛ての通信はSSEに送るべし」というルールを強力に握りしめたままだと、どうなるでしょうか。

[端末] → [オフィスのLAN] → [一度インターネットに出てSSEクラウドへ] → [社内のZTNAコネクタ] → [社内システム]

オフィスにいるにもかかわらず、わざわざ一度インターネットに出てクラウドを経由して足元の社内に戻ってくるという「大いなる無駄（Uターン現象・ヘアピン通信）」が発生します。これが劇的な遅延やパケットロス、セッション切断を引き起こす犯人です。

解決策：端末に「今、オフィスにいるよ」と気づかせる（ロケーション認識）

この経路競合を根本的に防ぐための機能が、SSEエージェントに備わっている「ロケーション認識（Trusted Network Detection）」です。

これは端末が「今、自分が会社の信頼できるネットワーク（オフィスLAN）にいるか、それとも自宅やカフェにいるか」を自動で判定する仕組みです。

判定の結果「オフィスにいる」と分かった場合：端末のエージェントは自動的にZTNA機能（特定のトンネル）をOFFにします。
通信のコントロールを譲る：これにより、社内システムへのルーティングはオフィスの賢い「SD-WANルーター」側に一任され、無駄のない最短ルートでの通信が可能になります。

よくある「DNS判定」だけで運用するリスク

では、エージェントはどうやって「ここは会社だ」と判定しているのでしょうか。

最もメジャーで設定が簡単なのは、「DHCPから払い出されるDNSサーバーのIPアドレス」や「特定の社内DNSサフィックス（接続ドメイン名）」を条件にする方法です。

例：「端末に払いだされたDNSサーバーが192.168.11.1の場合、オフィスとみなす」

一見これで完璧に思えますが、これ単体の条件（単一条件）で設計すると、運用後に罠にハマる可能性があります。

「たまたまユーザーが自宅で使っている市販ルーターのIPアドレスや、外出先のWi-Fi環境が、社内のDNSサーバーのIPアドレスと奇跡的に被ってしまう」というケースが実務上ネットワークを大規模に展開すると一定数発生するからです。

もし自宅なのに「社内にいる」と誤判定（誤バイパス）されてしまうと、今度は在宅環境から社内システムに一切繋がらなくなるという、逆パターンの重大な障害を引き起こします。

ロケーション認識に使える条件一覧と「掛け算」設計のベストプラクティス

例えばZscalerの接続エージェント（以下ZCC）では、端末が「社内ネットワーク（Trusted Network）にいるか」を判定するために、非常に多彩なトリガーが用意されています。

公式ドキュメントによると、主に以下のような要素を判定基準として利用できます。

ZCCで利用可能な社内判定要素

設定項目	概要	実務での評価・注意点
Network Name	接続しているWi-FiのSSID名など。	自宅のSSIDと同じ名前に偽装されるリスクがあるため、単体利用は非推奨。
DNS Servers	払い出されているDNSサーバーのIPアドレス。	メジャーな判定方法だが、自宅ルーターのIP（`192.168.1.1`など）との重複に注意。
DNS Search Domains	DNS検索サフィックス（例: `yourcompany.local`）。	企業特有のドメインを指定できるため、信頼性が高い。
Hostname or IP	特定の社内ホストにPingが通るか、またはIP。	社内限定のWebサーバーなどを指定すると有効。
Network Range	端末に割り当てられたIPアドレスの範囲。	自社のオフィスセグメント（例: `10.x.x.x`）を正確に指定可能。
Default Gateway	接続しているネットワークのデフォルトゲートウェイ。	ルーターのIPやMACアドレスを条件にできる。
DHCP Server	DHCPサーバーのIPアドレス。	社内のDHCPサーバーを指定。これも自宅ルーターとの重複リスクに注意。
Egress IP	端末がインターネットに出る際のグローバルIP。	オフィスの固定グローバルIPを指定。最も確実だが、拠点が多いと管理が煩雑に。

設計のベストプラクティス

これだけ多くの条件がありますが、前述の通り「1つだけの条件（例: DNS Serversだけ）」で設計するのは少し危ないです。

実務で誤判定を防ぎつつ、運用管理の手間を最小限に抑えるための掛け算（AND）構成は以下の組み合わせです。

【推奨設定パターン】

DNS Search Domains（自社専用ドメイン）※これだけでも十分

AND

Network Range（オフィスのローカルIP帯）または DNS Servers（社内DNSのIP）

このように、「外部からは絶対に名前解決できない社内ドメイン（DNS Search Domains）」という論理的な条件に、「自社が管理しているオフィスのネットワークセグメント（Network Range）」という物理的な条件を掛け合わせることで、自宅のWi-Fiやカフェの環境と「奇跡の一致」を起こすリスクを完璧に排除できます。