以前、Exchange Serverの災対連携構成について書いたのだけど、その頃の構成について図を掲載してみる。

こんな風に、メールボックス・ハブトランスポートに関してはほぼ冗長構成を取っているのだけど、唯一弱点として「CLIENT-ACCESS」機能は冗長化されて居ないと言うことが挙げられる。本来はNLB（Windowsの標準機能で提供される負荷分散）を使用するところなんだけど、めんどくさくて着手してなかったというのが正直なところ。

今回、CLIENT-ACCESSの経路をOutlook Web Access（以下、OWA)に限定する前提を置き、この機能の冗長化に取り組んでみた。ざっくりした構成は以下の通りである。

今回、UTM（Astaro Security Gateway)の機能である「Webアプリケーションファイアウォール」を使用することにした。元々この機能はSQLインジェクションなどを使用したWeb改ざんからWebサイトを保護する機能なのだけど、大抵この手の機能には付加機能としてロードバランシング機能が搭載されていたりする。今回、セキュリティと可用性を維持すると言うことでこの機能を使ってみた。

まず、UTMの管理コンソールにログインし、「サイト間VPN」⇒「証明書管理」⇒「新規証明書」を選択して証明書の作成画面に移動する。

以下のように作成画面は表示される。

1. 名前は任意で結構。
2. メソッドは「生成」を選択
3. 鍵サイズは任意で良いけど、せっかくデフォルトで2048ビットが選択されているのでそのまんまで。
4. VPN IDタイプは「ホスト名」
5. VPN IDは適当なホスト名を付与する。今回小生はこのクライアントアクセス用仮想IPに割り当てられているホスト名を指定した。
6. 国・市・組織はデフォルトのままでOK。「Save」をクリックする。

続いて、実際に接続先となるサーバを指定する。「アプリケーションセキュリティ」⇒「Webアプリケーションファイアウォール」⇒「本サーバ」タブ⇒「新規本サーバ」を選択。

作成画面が以下の通り表示されるので、以下のようにして設定する。

1. 名前は任意で良い。（単なる表示名）
2. ホストは、実際に接続するホストとなるネットワークオブジェクトをドラッグ＆ドロップで指定する。
3. タイプはSSL(HTTPS)とし、ポート番号は443に指定。
4. 「Save」ボタンをクリックする。

小生が追加した状態のものを例示しておく。POPULUS（災対サーバ）、YAKUSUGI（本番サーバ）が該当する。

続いて仮想サーバを作る。「仮想Webサーバ」タブ⇒「新規仮想Webサーバ」ボタンをクリックする。作成画面が出たら以下方針に従って設定をする。

1. 名前は任意（単なる表示名）
2. タイプは「SSL(HTTPS)」を指定
3. 証明書は、先述手順にて作成した証明書を選択する。
4. ドメインは、実際にURLとして指定するホスト名を指定する。小生は「仮想ホスト名」「災対サーバ実ホスト名」「本番サーバ実ホスト名」の3つを指定している。
5. インタフェースは、仮想IPを割り当てることになるインタフェースを指定する。小生は「DMZインタフェース」を指定している。
6. ポートは443
7. 本サーバの欄から「災対本サーバ」「本番本サーバ」のみチェックをつける
8. プロファイルを選択する。プリセットで「Advanced Protection」「Basic Protection」の2つが存在するが、今回は「Basic Protection」を指定した
9. 全て設定したら「Save」をクリックする。

小生が作成した設定を例示しとく。以下の通りとなっている。ちなみに「Domains」で指定するFQDNはちゃんと実アクセスする際のURLに合わせて定義しておかないと、Webアプリケーションファイアウォールの機能でアクセス拒否されてしまう（Forbiddenになっちゃう）ので要注意。おそらくIPベースでアクセスされることを防ぐためにそうなってる・・・・・のかなぁ？それとも、ApacheのReverse Proxy機能の制限なんかね？

その後、Exchangeサーバにログインし、Exchange Server管理コンソールを起動する。

「サーバの構成」⇒「クライアントアクセス」にて、クライアントアクセスサーバ設定画面を呼び出す。

それぞれのサーバの「Outlook Web Access」タブ⇒owaを右クリックし、内部URLおよび外部URLを「https://(仮想サーバのFQDN)/owa」に設定して「OK」をクリックする。

この後、外部向けルーターの443ポートをUTMに通すようStatic NATを構成しておく。

また、仮想サーバ・本サーバのFQDNが名前解決できるよう、DNSサーバの設定を修正し、ルートDNSサーバが更新され、正しくインターネット経由での名前解決が行える状態にする。

・・・・・・・・・・・・・・・・・・・・・・・・という感じで何とか負荷分散構成ができあがった。

一応上記はUQ-Wimaxにてインターネットに直接つないだ状態から、Chromeを使ってOWAを起動してみたの図。それぞれSSL接続に自己証明書を使用しているため、結構余計に確認画面が表示されることになるけど、動作自体はそれほど悪くないと思う。

Microsoftという会社はそれこそソフトウェアベンダー故なのか、何でもかんでもソフトウェアで片付けようとするのだけど、現実的にクライアントアクセスサーバはロードバランスを使用することが多いのかなと。その場合、今回のようにちゃんとロードバランサーやセキュリティアプライアンスの機能を把握した上で対応しないとまずいんだなと言うことで。自己証明書を採用している場合、そのCAの構成なんかもきっちり把握してないと、トラブルの元になりますんで要注意ですかね。