Office 365繋がらない問題に対してSD-WANで解決する際のプロキシサーバに関する考慮事項（前編）

弊社がお客様と会話をする中で、Office 365の負荷を軽減するソリューションに関する話題が今、非常に多くなっています。実際にヒアリングを重ねると、Office 365のトラフィックの急増によって、データセンターに設置されたセキュリティ機器の中でも、特にプロキシサーバの負荷が上がって、ユーザーに悪影響を及ぼしてしまっているようです。

この課題に対して、プロキシサーバに集中しているインターネットのトラフィックの中で、Office 365のトラフィックだけを直接インターネットへ出したい、それをSD-WANで実現できないか？というような依頼を受けます。

SD-WANのソリューションとしてはOffice 365のローカルブレークアウトがありますが、プロキシサーバを使用している構成に対してこのローカルブレークアウトを単純に導入することはできません。それは、プロキシサーバを経由する通信としない通信では、その方法に違いがあるためです。

今回のブログでは、なぜプロキシサーバを経由する通信に対して、SD-WANによるOffice 365のローカルブレークアウトを導入することが難しいのか。さらに弊社が提供するVersa Networks社のソリューションによってどのように解決ができるかについて
2回にわたってご紹介したいと思います。
注：ここでいうプロキシサーバは特に断りが無い限りすべてHTTP/HTTPSのプロキシサーバとなります。

Office 365のローカルブレークアウトを可能にするSD-WANのテクノロジー

まず、多くのSD-WANベンダーが持っている一般期なOffice 365のローカルブレークアウトについて見ていきたいと思います。
代表的な構成として、各拠点の業務端末が、セキュリティアプライアンスが集中しているデータセンターを経由してインターネットへ接続を行う場合を見ていきましょう。

各拠点のCPE(Customer Premises Equipment：顧客内設備)はトラフィックの内容を見てアプリケーションを判別し、Office 365のトラフィックを直接インターネットへ転送します。それ以外のトラフィックは、従来どおりデータセンターを経由してインターネットに到達します。この機能は、通過するパケットやフローを見るDPI (Deep Packet Inspection) 機能と、識別したアプリケーションを条件として、任意のネクストホップに転送するルーティングの機能で実現されています。

この機能の名称は各社で若干の違いがありますが、おおよそアプリケーション・アウェア・ルーティング (Application aware routing) や、アプリケーション・ステアリング (Application Steering) などと言われています。

Office 365に代表されるSaaS形態のサービスは、使用するIPアドレスやFQDNが頻繁に変更されますが、ほとんどのSD-WANベンダーがFQDNやIPアドレスの定義を更新しているので、問題なく対応することが可能です。暗号化されていますが、暗号化されたトラフィックでも基本的には問題なく識別が可能です。

プロキシサーバを経由するトラフィックについて

次にクライアントはそもそもプロキシサーバとどのように通信をしているのか、について見ていきたいと思います。

プロキシサーバを導入している企業では、各拠点にある業務端末に事前にプロキシサーバのIPアドレスまたはFQDNを設定し、クライアントがWebサーバと通信をする場合には、必ず事前に定義されたプロキシサーバを経由してインターネットに到達します。
例えば図1の構成で、クライアントがDataCenter内のプロキシサーバを経由して、Office365を閲覧する場合、どのように通信を行うかを見ていきましょう。

ここでは、Office 365のFQDNをwww.example.comであると仮定します。クライアントがwww.example.comにアクセスすると、まずプロキシサーバとTCP 3ウェイハンドシェイク (以下、TCP 3whs) を行います。そして、接続したいFQDNをHTTP CONNECT methodを使用して通知します。ちょうど図の黄色にハイライトされている部分です。これは暗号化されず平文で行われます。プロキシサーバは通知されたFQDNをDNSで名前解決し、接続先のホストとTCP 3whsを確立します。その後、端末に HTTP 200 OKのステータスコードを送信し、端末はSSLハンドシェイクを開始します。SSLハンドシェイクについては、プロキシサーバは中身を特に見ることはなく基本的に転送するだけです。そして、クライアントは最終的に暗号化された通信でサイトを閲覧することができます。

このような通信にあくまでルーティングしか行わないアプリケーション・ステアリングを単純に適用したとしても、宛先IPアドレスが組織内DataCenterのプロキシサーバのもののままでインターネットに出て行ってしまい、パケットがそもそもOffice365サイトに到達せず、通信はできません。

プロキシ経由の通信のローカルブレークアウトを実現する機能

プロキシ経由の通信のローカルブレークアウトは、単なるアプリケーション・ステアリングではなく、 同じプロキシの機能を使って行う必要があります。ではどのような機能が必要となるのかその機能を挙げていきたいと思います。

プロキシチェイニング機能

プロキシの機能を使用してOffice 365のローカルブレークアウトを行い、他の通信は通常どおり転送を行うという要件を実現するためには、一旦プロキシのTCPハンドシェイクを終端し、Office 365以外の通信は、別のプロキシサーバに転送する機能が必要となります。このような機能は一般的にプロキシチェイニング (Proxy Chaining) や、プロキシフォワーディング (Proxy Forwarding)と呼ばれます。
一般的なプロキシチェイニングサーバを導入する場合、クライアントのプロキシサーバの設定には、プロキシチェイニングサーバのIPアドレスまたは、FQDNを設定します。そして、クライアントは、プロキシチェイニングサーバに対して、Webの通信を行います。また、プロキシチェイニングサーバには、転送したいFQDN(例えばwww.example.net)と、転送先のウェブ プロキシを指定します。

※DNSの通信フローは省略しました

プロキシチェイニングの動作の一例を見てみましょう。ここでは、プロキシチェイニングサーバに対して、www.example.netのFQDNにマッチした場合には、プロキシサーバに対して転送するという設定が入っています。先程の通信と同様にクライアントがhttps://www.example.netにアクセスすると、クライアントはプロキシチェイニングサーバとHTTP CONNECT methodまでの通信を行います。このときのFQDNが事前定義したものにマッチすると、プロキシチェイニングサーバが転送先のプロキシサーバに対して、TCP 3whsを確立しHTTP CONNECT methodを送信します。その後、プロキシサーバはプロキシチェイニングサーバにHTTP 200 OKのステータスコードを返し、さらにプロキシチェイニングサーバはクライアントにも同様に送信します。その後の、TLSハンドシェイクは先程説明した一般的なプロキシサーバの通信のしかたとほとんど同じです。また、FQDNが事前定義したものにマッチしない場合には、図3で示したような通信を行います。

導入構成の柔軟性のための透過型プロキシ機能

さらに、導入構成が課題になる場合もあります。例えば、クライアントのプロキシサーバの設定を変更することができない場合や、プロキシサーバ自体のIPアドレスの設定変更が困難な場合があります。導入構成をより柔軟にするために透過型プロキシやトランスペアレントプロキシ(Transparent Proxy)といった機能が必要になる場合があります。

Office 365のFQDNの自動更新機能

プロキシチェイニングができたとしても、実際の機器設定では、チェイニングしたいFQDNを定義する必要があります。しかし、Office 365のFQDNやIPアドレスは頻繁に変更されています。自前で設定変更と管理を行うことは難しいため、別途、自動更新サービスの契約や、API/スクリプト連携が必要となります。

トラフィックの負荷分散と障害時の切り替えのためのサーバロードバランシング機能

プロキシサーバの耐障害性と負荷分散のために、複数のプロキシサーバを並べて運用する場合があります。これを実現するためには、プロキシチェイニングに加えて、一箇所のプロキシサーバに偏ることなく、セッションを割り振る機能、すなわちサーバロードバランシング機能が必要となります。また、プロキシサーバの片方に障害が発生したら、別の正常な方に切り替えて通信を行うヘルスチェック機能も必要です。

ここで挙げた機能は一部のロードバランサーやプロキシ製品にはありますが、それらをSD-WANのようにすべての拠点で導入するには、コストの面で導入が難しい場合があります。また、残念ながらこれらのソリューションを提供できるSD-WANベンダは限られています。

■後編はこちらから
Office 365繋がらない問題に対してSD-WANで解決する際のプロキシサーバに関する考慮事項　後編