SD-WANアーキテクチャとインターネットブレイクアウト制御

本記事はNWの午後試験・科目B群の学習を支える技術解説です。演習と解答例は当サイトのオリジナルで、IPAの公式問題・公式採点基準ではありません。製品ごとの設定差や、問題文で仮定した条件を区別して読み進めてください。

1. 概要と本質：なぜ従来の企業WANは破綻したのか

長年にわたり、全国に支社や工場を持つ日本企業の企業ネットワークは、すべての拠点間通信を本社やデータセンタ（DC）へ集約する「ハブ＆スポーク型WAN」で構築されてきました。 高信頼な通信キャリアの閉域網（IP-VPNや広域イーサネット）を契約し、すべての社外インターネット向け通信を本社DCのプロキシサーバやファイアウォール経由で一本化する構成です。

しかし、Microsoft 365、Google Workspace、Zoom、BoxなどのクラウドSaaSが業務の中心となったことで、このアーキテクチャは完全に限界を迎えました。

1. トラフィックの爆発的急増: Web会議の常時接続やファイル同期により、拠点〜本社間の高価なMPLS回線帯域が枯渇。

2. 本社ゲートウェイのボトルネック化（ヘアピン現象）: 拠点からクラウドへアクセスするだけなのに、わざわざ本社DCを往復（ヘアピン）するため、プロキシやファイアウォールのセッション数が飽和し、全社的な通信遅延が発生。

3. 高額な回線コスト: 帯域増強のために閉域網回線を契約し続けると、通信コストが青天井に跳ね上がる。

この問題を解決するのが、物理回線に依存せず、ソフトウェアによってWAN全体をインテリジェントに集中制御する「SD-WAN（Software-Defined Wide Area Network）」です。 ネットワークスペシャリスト（NW）午後・科目B試験では、「アンダーレイとオーバレイの分離」「DPIによるアプリケーション識別」「特定SaaS宛てトラフィックを拠点から直接インターネットへ逃がす『インターネットブレイクアウト（ローカルブレイクアウト）』」「回線品質（遅延・ジッタ・ロス）に応じた動的パスマネジメント」が近年の頻出重要テーマとなっています。 本稿では、その技術詳細と設計の勘所を徹底解説します。

2. SD-WANの全体アーキテクチャ

SD-WANは、SDN（Software-Defined Networking）の思想を広域ネットワークに適用したものであり、3つのプレーン（階層）で構成されます。

2.1 アンダーレイとオーバレイの分離

3. DPI（ディープパケットインスペクション）とSaaS識別

SD-WANが通信をインテリジェントに振り分けるためには、流れてきたパケットが「Microsoft 365の通信か」「YouTubeの動画視聴か」「社内基幹DBの通信か」を正確に識別する必要があります。

宛先IPやポート443だけでは、IPを共有する複数サービスを十分に区別できない。SD-WANのアプリケーション識別では、DPIに加えて公開IP/FQDNリスト、DNS情報、可視のTLS SNIなどを利用する。暗号化されたHTTP本文を直接読めるとは限らず、識別できる範囲は製品・通信方式に依存する。

• 識別の手がかり:

1. DNS問合せ（FQDNキャッシュ）: 端末が事前に行ったDNSクエリのドメイン名とIPアドレスの対応を学習。 2. TLS ClientHello内のSNIフィールド: 通常のClientHelloでは接続先FQDNを確認できるが、ECH等で隠れる場合がある。 3. Microsoft/Googleが公開する最新IPアドレス/URLリストの自動同期（API連携）。

4. インターネットブレイクアウト（ローカルブレイクアウト）の設計

全トラフィックを本社データセンタへ送るのではなく、「特定SaaSの通信のみを拠点ルータから直接インターネットへ逃がす（ブレイクアウトする）」設計です。

4.1 ブレイクアウト設計時のセキュリティ対策

ブレイクアウト対象のリスクと要件に応じて、拠点FW、SWG、端末防御、認証、監視を組み合わせる。以下は構成例であり、すべての導入で同じ転送方式が必須となるわけではない。図の一般Webは本社プロキシへ送る例で、クラウドSWGへの転送は別の選択肢である。

• ブレイクアウト対象の限定: Microsoft 365やZoomなど、送信先が明確かつ信頼できるホワイトリストSaaSのみに限定する。

• 一般WebアクセスのSASE（クラウドプロキシ）転送: その他の一般Web閲覧は、直接インターネットへ出すのではなく、要件に応じてクラウド型SWG（セキュアWebゲートウェイ）へ転送してウイルス検査やURLフィルタを実施する。

5. ダイナミックパスマネジメント（回線品質の動的選択）

SD-WANの真骨頂は、複数のアンダーレイ回線（例: 「高信頼だが狭帯域なMPLS」＋「安価で広帯域だが品質が不安定な一般インターネット光回線」）を束ね、リアルタイムの回線品質に応じてパケットの送信経路を自動的に切り替える「動的経路選択」です。

• 常時品質監視: エッジルータ間で微小なプローブパケット（BFDや独自UDPプローブ）をミリ秒間隔で送受信し、「遅延（Latency）」「ジッタ（Jitter: 揺らぎ）」「パケットロス率」 をリアルタイム計測。

• アプリケーション別SLAポリシー:

- 音声通話（VoIP / Teams通話）: 「パケットロス 1%以下、ジッタ 10ms以下」を要求。通常はMPLS回線を通し、MPLS障害時は即座にインターネットVPNへ設定とセッション維持条件に応じた切替。 - 大容量ファイル転送・バックアップ: 帯域の広さを最優先し、広帯域な「インターネット光回線」へ優先ルーティング。

6. 午後・科目B形式 実戦演習

【問題シナリオ】

全国に80か所の拠点を展開する小売流通大手のL社は、社内情報共有基盤をオンプレミスのメール・ファイルサーバから、クラウド型の「Microsoft 365」へ全面移行した。 L社のネットワークは、各拠点から本社データセンタ（DC）へIP-VPN（帯域：各拠点10Mbps）で接続し、本社DCに設置されたプロキシサーバ（Proxy-GW）を経由してインターネットへ抜けるハブ＆スポーク構成を採用している。

移行後、全拠点で「メールの送受信が極端に遅い」「SharePointへのファイル保存がタイムアウトする」「Teamsのビデオ通話が頻繁にフリーズする」という深刻な業務遅延が発生した。 ネットワーク監視ツールで調査したところ、以下の事実が判明した。

1. 各拠点と本社DCを結ぶIP-VPN回線（10Mbps）の帯域使用率が、始業直後から夕方まで終日95%以上に張り付いていた。

2. 本社DCのプロキシサーバ（Proxy-GW）において、CPU使用率が100%に達し、同時接続セッション数が機器の上限値を超過していた。

L社の情報システム部は、この問題を根本解決するため、全拠点にSD-WANエッジルータを導入し、安価な一般インターネット光回線（ベストエフォート1Gbps）を各拠点に追加敷設して「インターネットブレイクアウト」を実施する計画を策定した。

【設問1】

L社において、Microsoft 365の利用開始に伴い、本社DCのプロキシサーバ（Proxy-GW）のCPU使用率およびセッション数が上限に達して枯渇した原因について、Microsoft 365の通信特性（コネクションの保持動作）に着目して35字以内で述べよ。

解答への思考プロセス

• Microsoft 365の通信特性:

- 一般的なWeb閲覧は「リクエストを投げてレスポンスを受け取ったら切断」する短寿命セッションが多い。 - しかし、Microsoft 365（Outlookのプッシュ通知、Teamsのプレゼンス情報、SharePointの更新待機等）は、リアルタイム同期のために1台のクライアント端末がアプリに応じた複数のTCPコネクションを常時張ったまま維持（長寿命接続・常時接続）する。 - 全80拠点の数千台のPCが一斉に常時接続を確立したため、プロキシサーバが管理すべきセッション数が天文学的に膨れ上がり、セッションテーブルとリソースが枯渇した。

• 設問要求の確認:

- 「Microsoft 365の通信特性（コネクションの保持動作）」に着目。 - 35字以内。

• 文章作成: 設問が求める原因・動作を短く整理し、以下の解答例のようにまとめる。

- 端末が多数の長寿命な常時接続コネクションを確立・維持するため。

模範解答

端末が多数の長寿命な常時接続コネクションを確立・維持するため。

解答で確認したい論点

• ×「メールの容量が大きすぎてメモリを食いつぶしたため。」（セッション数枯渇の本質である常時接続の仕組みに触れていないため不十分。論点不足）

• △「アクセス数が多かったため。」（抽象的すぎてMicrosoft 365の固有特性を説明できていないため必要な論点が不足）

【設問2】

L社が各拠点にSD-WANエッジルータを導入し、Microsoft 365宛てのトラフィックのみを拠点から直接インターネットへローカルブレイクアウトさせる際、エッジルータが通信パケットの中からMicrosoft 365宛ての通信を正確に識別・抽出するために利用する技術の名称を20字以内で答えよ。

解答への思考プロセス

• 技術用語の特定:

- ポート番号443（HTTPS）だけでは一般WebとSaaSを識別できないため、パケットのペイロードや平文ヘッダ（SNI等）を詳細に解析する技術が必要。 - このアプリケーション識別技術の標準呼称は 「DPI」 または 「ディープパケットインスペクション」（Deep Packet Inspection）。

• 字数制限（20字以内）への整形:

- 「ディープパケットインスペクション（DPI）」 - 「DPI（ディープパケットインスペクション）」 - 「ディープパケットインスペクション」

模範解答

DPI

解答で確認したい論点

• ×「ステートフルインスペクション」（L3/L4の状態監視であり、L7アプリケーション識別機能ではないため誤り）

• △「パケットキャプチャ」（キャプチャは保存・観察行為であり、リアルタイムのアプリ識別機能の名称ではないため論点不足）

7. まとめと次ステップ

SD-WANは、クラウド時代における企業WANの帯域ボトルネックを劇的に解消する救世主です。

• コントロール／データプレーン分離により、全拠点のルーティングと暗号化トンネルを一元管理。

• DPIにより、可視のメタデータ等を使って業務SaaSを識別。

• インターネットブレイクアウトで、本社DCのヘアピン現象と回線逼迫を負荷を低減。

• 動的パスマネジメントで、遅延・ジッタ・ロスを監視し、VoIP等の重要通信の品質を担保。

次稿 NWP-15（IPv6移行技術（MAP-E・DS-Lite・464XLAT）とデュアルスタック運用） では、世界的なIPv4アドレス完全枯渇の現実と、日本の家庭・企業ネットワークを支えるIPv6 IPoE（IP over Ethernet）接続、およびIPv4 over IPv6カプセル化技術のメカニズムを徹底解説します。

暗号化通信の識別と経路変更の制約

DPIが暗号化されたHTTP本文をそのまま読めるわけではない。通常は可視のSNI、DNS情報、公開されたIP/FQDNリスト等を組み合わせる。ECHでSNIが隠れたり、暗号化DNSで問合せを観測できなかったりする場合があるため、誤分類とリスト更新を設計する。

新規TCP接続は最初のSYNから経路が必要である。ClientHello確認後にNATアドレスを変えると既存接続が壊れるため、事前リストで分類する、接続開始時の経路を固定する、または透過的に扱えるオーバレイを利用する。SNIを読むだけで確立済み接続を任意の出口へ移せるとは限らない。

Microsoft 365や一般Webの接続数・保持時間はアプリによって異なる。WebのKeep-AliveやHTTP/2多重化もあり、1端末が常に数百TCP接続を張るとは断定しない。演習では多数の端末の長寿命接続がプロキシの上限を超えたことを観測済みとする。

管理・制御・データのプレーン分離は代表的モデルで、各製品の構成は異なる。回線切替時の無瞬断は保証されない。ブレイクアウトにもFW、利用者認証、端末防御、適切なSaaSの推奨経路とポリシーが必要で、SWGへの転送を全サービスへ一律に強制するものではない。

参考資料・関連する学習記事

公式技術資料（learn.microsoft.com）

次に読む：IPv6移行技術（MAP-E・DS-Lite・464XLAT）とデュアルスタック運用