ローカルブレイクアウトの設計

読み：ろーかるぶれいくあうとのせっけい　／　英語表記：local breakout design

特定のクラウドサービスなどへの通信を拠点側からインターネットへ出し、本社への通信の集中を抑える設計である。宛先に応じたプロキシの選択、拠点間VPN、アドレス変換、ログの取得を整合させる必要がある。

イマシルちゃんの解説

支社のパソコンがクラウドサービスを使うたびに本社を経由すると、本社の回線やプロキシサーバに通信が集まってしまうんだ。
ローカルブレイクアウトは、選んだ通信を支社側からインターネットへ出す接続方式だよ。
例えば特定のクラウドサービスには支社のプロキシを使い、それ以外のWebサイトには本社のプロキシを使うように分けられるんだ。
設定するときは、どのプロキシを選ぶかと、その先で通信がどこを通るかを両方確認するよ。
必要なログや検査を受けられる場所もそろえることで、管理に必要な機能を保ちながら通信の集中を減らせるんだ。

より深い解説

本社に集める通信と拠点から出す通信を決める

本社を中心に各支社を結ぶハブアンドスポーク型のVPNでは、支社からのインターネット通信も本社へ集約する構成を取りやすい。プロキシやセキュリティ機器を一か所で管理できる一方、クラウドサービスの利用が増えると本社の回線、VPN装置、プロキシに負荷が集中する。

ローカルブレイクアウトでは対象の通信を選び、支社側の出口を使う。全てを一律に移す必要はなく、対象サービスと必要な検査内容を決めて段階的に導入できる。

UTMは複数のセキュリティ機能をまとめた装置である。プロキシ機能が標準で使えるとは限らず、必要なライセンスと処理性能を確認する。HTTPSだからログや制御が不要になるわけではない。

出口を変更すると、外部サービスから見える送信元IPアドレスも変わり得る。支社のNAPT設定と、送信元アドレスを制限しているSaaS側の設定を対応させる。移行後も利用者を特定できるよう、時刻、端末、変換後のアドレスを結び付けて追えるログを用意する。

プロキシの選択とパケットの経路を区別する

ブラウザがプロキシを使う場合、まず選んだプロキシへ接続し、その装置が宛先への通信を中継する。プロキシを使わない場合は、ブラウザがアクセス先へ直接接続する。ただし、そのパケットがどの回線を通るかは経路表やVPNの設定によって決まる。

このため、プロキシ設定のDIRECTは「プロキシを利用しない」という意味であり、「VPNを通らない」という指定ではない。本社の社内サーバへ接続するパケットは、プロキシを使わなくても支社と本社を結ぶVPNを通り得る。

HTTPSを明示的なプロキシで中継する一般的な方式では、ブラウザがCONNECTメソッドで接続先を指定し、トンネルを作る。接続を中継するだけの動作と、証明書を用いてHTTPSを復号検査する動作は異なる。必要な検査の内容と端末への証明書設定を確かめる。

PACファイルで宛先ごとに選ぶ

PACファイルは、アクセス先に応じて利用するプロキシを返すJavaScriptの設定ファイルである。中心となる関数はFindProxyForURLで、アクセス先のURLとホスト名を受け取る。ファイルを置くサーバと、実際の通信を中継するプロキシサーバは別の役割を持つ。

例えば社内向けのドメインを先に判定し、次に指定したクラウドサービス、最後にそれ以外を判定する。次は仕組みを説明するための独自の設定例である。

function FindProxyForURL(url, host) {
  if (host === "intra.example" || dnsDomainIs(host, ".intra.example")) {
    return "DIRECT";
  }
  if (host === "cloud.example" || dnsDomainIs(host, ".cloud.example")) {
    return "PROXY branch-proxy.intra.example:3128";
  }
  return "PROXY central-proxy.intra.example:3128";
}

dnsDomainIsはホスト名の末尾が指定した文字列に一致するかを判定する。この例ではルートの名前そのものと、ドットを含むサブドメインの条件を分けている。条件に一致してreturnした時点で結果が決まるため、複数の条件が重なる場合は判定順も動作に影響する。

クラウドサービスは、画面のドメイン以外に認証や画像配信のドメインを使うことがある。必要な宛先をサービスの公開情報と通信ログで確認し、一部だけ意図しない出口へ流れないようにする。プロキシが利用できない場合の扱いも決め、許可していない直接接続へ自動的に切り替わる設定を残さない。

支社ごとにプロキシのFQDNが異なり、その名前をPACへ固定して書く場合は、支社ごとに設定を分ける必要がある。全社で一つのファイルを使えるかは、利用拠点を判別する方法と名前解決の設計による。同じファイルを配布できることと、どの場所でも正しいプロキシが選ばれることを区別する。

名前とIPアドレスによる条件を読み分ける

PACでは、ホスト名をIPアドレスへ変換するdnsResolve、アドレスが指定範囲に含まれるかを調べるisInNet、パターンに一致するかを調べるshExpMatchなどを使う。DNS問い合わせが必要な条件は名前解決の失敗や遅延にも影響されるため、判定結果と所要時間を確認する。

IPアドレスの範囲判定では、「端末へ割り当てられるアドレス」と「条件に一致するアドレス空間」を混同しない。独自の例として10.40.8.0/21を条件にすると、マスクは255.255.248.0で、範囲は10.40.8.0から10.40.15.255までになる。範囲を求めるときは先頭や末尾を取り除かない。

その中のどのアドレスが特定サブネットのネットワークアドレスやブロードキャストアドレスになるかは、割り当て先のサブネット設計で判断する別の問題である。プライベートIPアドレス宛てなら社内への経路が必ず存在する、とも限らない。PACの条件と実際の到達性をセットで確かめる。

PACファイルの配布方法を決める

PACの内容を端末へ使わせる方法には、ファイルのURLを指定する方法と、WPADで場所を自動検出する方法がある。WPADはPACの代わりに経路を決めるものではなく、PACファイルの場所を発見する仕組みである。

自動検出の対応状況や探す順序はOSやアプリケーションによって異なる。例えばMicrosoftのWinHTTPでは、両方式を有効にするとDHCPを先に試し、見つからなければDNSを利用する。全てのブラウザが同じ手順で動くとは限らない。

悪意のあるDHCP応答や偽のDNS情報によって不正なPACへ誘導されると、攻撃者の指定したプロキシへ通信を中継されるおそれがある。HTTPSの本文が必ず復号されるという意味ではないが、接続先の情報や平文の通信などが影響を受け得る。

管理対象の端末では、配布元のURLを管理設定で指定し、不要な自動検出を無効にする方法を検討する。指定先のサーバと配信経路も保護し、端末が更新後のファイルを取得できるかを確認する。

VPNのカプセル化と暗号化を別々に追う

ローカルブレイクアウトを導入した後も、社内向けの通信などには拠点間VPNが残る。暗号化範囲を読むときは、どのIPパケットへどの順でヘッダーを付けたかを確認する。ここではIPv4の基本形を考える。

IP-in-IPは元のIPパケットを別のIPパケットへ入れる技術であり、それ自体は暗号化を行わない。先にIP-in-IPで包むと、元のIPヘッダーも外側から見たペイロードの中に入る。その後のESPがトランスポートモードでも、内側の元のIPヘッダーまで暗号化対象になる理由はここにある。

既にIP-in-IPで包んだパケットへ、さらにESPのトンネルモードを適用するなら、IP-in-IPで付けたヘッダーも含めて保護対象になる。モード名だけから範囲を決めず、ESPを適用する直前のパケットを一つのまとまりとして追う。

ESPヘッダー自体と外側の配送に使うIPヘッダーは、ESPの暗号化範囲に含まれない。暗号化範囲と完全性検証の対象範囲も同じではないため、両方を混ぜて答えない。

鍵とパケットサイズも見直す

IPsecで相手を認証する方法には、事前共有鍵を使う方式がある。複数の拠点で同じ鍵を使い回すより、対向装置の組合せごとに分けた方が、漏えい時の影響範囲を限定しやすい。IKEで認証に使う事前共有鍵と、実際の通信を暗号化するために導出する鍵は区別する。

トンネルインタフェースのIP Unnumbered設定は、そのインタフェースへ専用のIPアドレスを割り当てない構成である。実装によって別インタフェースのアドレスを利用する。外側のパケットを送るためのIPアドレスまで不要になるわけではない。

トンネルではヘッダーや認証データが増えるため、元のパケットをそのまま包むと経路のMTUを超えることがある。フラグメンテーションが発生すると、分割したパケットの処理や再構成の負荷が増える。

TCPではMSSを適切に調整して、トンネルを通るパケットが過大にならないようにする方法がある。必要な余裕はIPsecの方式や暗号方式によって異なり、固定の値を機械的に引くのではなく使用する構成で計算する。MSS調整はTCPの対策なので、UDPなどについてはMTUやパスMTU探索を別に確認する。

変更後の通信を確認する

検証では「ページが表示された」だけで終わらせず、社内向け、対象SaaS、その他のWebサイトを分ける。それぞれで選ばれたプロキシ、通過した回線、外部から見える送信元アドレス、残ったログを確認する。

VPNが必要な通信については、変更前の経路と暗号化が維持されていることを確かめる。支社のプロキシや回線が故障した場合も試し、アクセスを停止するのか、承認済みの代替経路を使うのかを決めておく。

参考資料

• IPA「令和6年度春期」問題・解答例・採点講評のネットワークスペシャリスト午後Ⅰ問3。
• MDNのPACファイル解説で戻り値と各関数の条件を確認できる。
• MicrosoftのWinHTTP自動プロキシ資料と自動検出に関する注意事項でWPADの手順を確認できる。
• RFC 4303でESPのモードと暗号化範囲を、RFC 7296でIKEv2の認証と鍵の扱いを確認できる。
• RFC 1191とRFC 8900でMTUと分割処理の注意点を確認できる。

午後での問われ方

実際の試験ではここに出る！全1問

ネットワークスペシャリスト

午後Ⅰ

• R6春 問3

この用語が出てくる記事

• ローカルブレイクアウト