この章では、Proxy Server を逆プロキシとして使用する方法について説明します。逆プロキシは、ファイアウォールの外側で使用され、外部のクライアントに対してはセキュリティー保護されたコンテンツサーバーに見せかけます。これは会社のサーバーのデータが外部から直接、監視されずにアクセスされることを防ぎます。また、レプリケーション用に使用することもできます。つまり、アクセス回数の多いサーバーの前に複数のプロキシを接続して、負荷を分散することができます。この章では、Proxy Server をファイアウォールの内側または外側で交互に使用できるようにする方法について説明します。
この章の内容は次のとおりです。
逆プロキシには 2 つの方法を使用できます。一方の方法では Proxy Server のセキュリティー機能を利用してトランザクションを処理します。他方の方法ではキャッシング機能を利用してアクセス回数の多いサーバーの負荷を分散します。どちらの方法も、厳密にファイアウォール上で動作しないため、従来のプロキシの使用法とは異なっています。
クレジットカード番号のデータベースなど、セキュリティー保護する必要のある機密情報を保持するコンテンツサーバーがある場合、このコンテンツサーバーの代理として、プロキシをファイアウォールの外側に設定することができます。外部のクライアントがコンテンツサーバーにアクセスしようとすると、代わりに Proxy Server に送られます。実際のコンテンツは、ファイアウォールの内側でセキュリティー保護されたコンテンツサーバー内にあります。Proxy Server はファイアウォールの外側にあり、クライアントからはコンテンツサーバーに見えます。
クライアントがサイトに対して要求を送ると、その要求は Proxy Server に送られます。次に、Proxy Server は、クライアントの要求を、ファイアウォール内の特定の経路を経由させてコンテンツサーバーに送信します。コンテンツサーバーも、この経路を経由させて結果をプロキシに返します。図 14–1 に示すように、プロキシは、実際のコンテンツサーバーのように見せかけて、取得した情報をクライアントに送信します。コンテンツサーバーがエラーメッセージを返してきた場合、Proxy Server は、このメッセージをクライアントに送信する前に、メッセージを遮断して、ヘッダーに表示された URL を変更することができます。この動作によって、外部クライアントにより内部のコンテンツサーバーに対するリダイレクト URL が入手されることを防ぐことができます。
このように、プロキシはセキュリティー保護されたデータベースを悪意のある攻撃から守るためのバリアとして機能します。万が一悪意のある攻撃が成功してしまった場合でも、侵入者は 1 つのトランザクションに関連する情報にしかアクセスできないように制限される可能性が高くなり、データベース全体にアクセスすることはありません。ファイアウォールの経路には Proxy Server しかアクセスできないため、承認されていないユーザーは実際のコンテンツサーバーにアクセスすることはできません。
ファイアウォールルーターを設定することによって、特定のポート上の特定のサーバー (この場合は割り当てられたポート上のプロキシ) が、ほかのコンピュータのアクセスを許可することなく、ファイアウォールを通過してアクセスできるようになります。
セキュリティー保護された逆プロキシが実行されるのは、Proxy Server とほかのマシンの間の 1 つ以上の接続で Secure Sockets Layer (SSL) プロトコルが使用され、データが暗号化されている場合です。
セキュリティー保護された逆プロキシには多くの使用法があります。
ファイアウォールの外側のプロキシサーバーからファイアウォールの内側のセキュリティー保護されたコンテンツサーバーへの接続を暗号化します。
クライアントがプロキシサーバーに安全に接続できるようにし、情報 (クレジットカード番号など) の転送のセキュリティーを保護します。
セキュリティー保護された逆プロキシを使用すると、データの暗号化に伴うオーバーヘッドによって、セキュリティー保護された各接続の速度が低下します。しかし、SSL の提供するキャッシングメカニズムによって、接続している両者は以前に更新済みのセキュリティーパラメータを再利用することができ、以降の接続のオーバーヘッドを大幅に減らすことができます。
セキュリティー保護された逆プロキシは、次の 3 つの方法で設定できます。
セキュリティー保護されたクライアントからプロキシへ: このシナリオは、次の図に示すように、プロキシとコンテンツサーバー間でやりとりされる情報が、承認されていないユーザーからアクセスされる可能性がほとんど、またはまったくない場合に効果的です。
セキュリティー保護されたプロキシからコンテンツサーバーへ: このシナリオは、ファイアウォールの内側にクライアントがあり、コンテンツサーバーがファイアウォールの外側にある場合に効果的です。このシナリオでは、次の図に示すように、Proxy Server はサイト間のセキュリティー保護されたチャネルとして機能します。
セキュリティー保護されたクライアントからプロキシへ、およびセキュリティー保護されたプロキシからコンテンツサーバーへ: このシナリオは、サーバー、プロキシ、およびクライアント間でやりとりされる情報をセキュリティー保護する必要がある場合に効果的です。このシナリオでは、次の図に示すように、Proxy Server はサイト間のセキュリティー保護されたチャネルのように機能し、クライアント認証についてもセキュリティー保護します。
これらの設定の各設定方法については、「逆プロキシの設定」を参照してください。
プロキシは SSL のほかにもクライアント認証を使用することができます。このためには、プロキシに対して要求を作成するコンピュータが、識別情報を検証するための証明書または他の ID の形式を提示する必要があります。
組織内で複数のプロキシサーバーを使用して、Web サーバー間のネットワーク負荷を分散することができます。このモデルでは、Proxy Server のキャッシュ機能を利用して、負荷分散のためのサーバープールを作成します。この場合、Proxy Server はファイアウォールのどちら側に配置してもかまいません。1 日に大量の要求を受信する Web サーバーがある場合、プロキシサーバーを使用することで、この Web サーバーの負荷を減らし、ネットワークアクセスの効率を上げることができます。
Proxy Server は、実際のサーバーに対するクライアント要求の橋渡し役として機能します。Proxy Server は、要求されたドキュメントをキャッシュします。複数のプロキシサーバーが存在する場合、DNS は IP アドレスを「ラウンドロビン」方式で選択して、要求をランダムにルーティングすることができます。クライアントは毎回同じ URL を使用しますが、要求は毎回異なるプロキシを経由して送信されることがあります。
アクセス回数の多い 1 台のコンテンツサーバーへの要求を、複数のプロキシを使用して処理する方法には、サーバーが 1 台の場合と比べて、より大きな負荷を、より効率的に処理できるようになるという利点があります。最初の起動時に、プロキシがコンテンツサーバーからドキュメントをはじめて取得した後は、コンテンツサーバーへの要求数が大幅に減少する可能性があります。
コンテンツサーバーに送る必要があるのは、CGI 要求とときどき発生する新規の要求だけです。それ以外の要求は、プロキシで処理できます。たとえば、サーバーへの要求の 90% は CGI 以外の要求 、つまり、キャッシュ可能な要求で、1 日あたりのコンテンツサーバーへのヒット数は 200 万回であるとします。この状況で、3 つのプロキシに接続し、各逆プロキシが 1 日あたり 200 万回のアクセスを処理すれば、1 日あたり約 600 万回のヒット数を処理することもできるようになります。コンテンツサーバーに到達する要求は 10% なので、各プロキシからの 1 日あたりのヒット数は合計 20 万回、つまり全体で 60 万回程度となり、こちらの方がはるかに効率的です。ヒット数が約 200 万回から 600万回に増加しても、コンテンツサーバー上の負荷はそれに伴って 200 万回から 60 万回に減少します。ただし、実際の結果はユーザーの状況によって異なります。
逆プロキシを設定するには、2 つのマッピング、通常マッピングと逆マッピング が必要です。
通常マッピングは、要求をコンテンツサーバーにリダイレクトします。クライアントが Proxy Server にドキュメントを要求した場合、Proxy Server は通常マッピングによって、実際のドキュメントの取得先を知る必要があります。
自動設定ファイルを使用するプロキシがある場合は、逆プロキシを使用しないでください。プロキシが不正な結果を返すことがあるためです。
逆マッピングでは、Proxy Server がコンテンツサーバーからのリダイレクトにトラップをかけます。プロキシはリダイレクトを遮断し、リダイレクトされた URL を変更して Proxy Server にマップします。たとえば、クライアントが要求するドキュメントがほかの場所に移動されていたり、見つからなかったりした場合、コンテンツサーバーは、要求された URL でドキュメントが見つからないことを説明するメッセージをクライアントに返します。コンテンツサーバーは、返されたメッセージに、移動されたファイルの取得に使用する URL を示した HTTP ヘッダーを追加します。内部のコンテンツサーバーのプライバシーを守るために、プロキシは、逆マッピングを使用して URL をリダイレクトすることができます。
ここでは、http://http.site.com/ という Web サーバーがあり、このサーバーの逆プロキシサーバーを設定する場合を考えてみます。この場合の逆プロキシは http://proxy.site.com/ とします。
サーバーマネージャーにアクセスし、「URLs」タブをクリックします。
「Create Mapping」リンクをクリックします。
「Create Mapping」ページが表示されます。
表示されるページで、通常マッピングの「source prefix」と「source destination」を指定します。
たとえば、次のようになります。
「Source prefix」: http://proxy.site.com
「Source destination」: http://http.site.com/
[了解]をクリックします。
ページに戻り、たとえば、逆マッピングを作成します。
「逆マッピング」:
「Source prefix」: http://http.site.com/
「Source destination」: http://proxy.site.com/
変更を行うには、「了解」をクリックします。
「了解」ボタンをクリックすると、プロキシサーバーは 1 つ以上のマッピングを追加します。マッピングを表示するには、「View/Edit Mappings」というリンクをクリックします。追加されたマッピングは、次のような形式で表示されます。
「from」: /
「to」: http://http.site.com/
これらの追加の自動マッピングは、逆プロキシを通常のサーバーとして接続してくるユーザーを対象としています。最初のマッピングは、逆プロキシを通常のプロキシとして接続してくるユーザーを対象としています。"/" マッピングは、ユーザーが管理 GUI によって自動的に指定された「Map Source Prefix」テキストボックスの内容を変更していない場合にのみ追加されます。設定方法によりますが、通常、必要とされるのは 2 つ目のマッピングのみですが、余分なマッピングを設定してもプロキシに問題が発生することはありません。
Web サーバーに複数の DNS エイリアスが存在する場合、各エイリアスに対応する通常マッピングが必要です。Web サーバーが複数の DNS エイリアスによって、自分自身に対するリダイレクトを複数生成する場合、これらのエイリアスには、それぞれに対応する逆マッピングが必要です。
配信元サーバー上で CGI アプリケーションがまだ実行されています。Proxy Server が単独で CGI アプリケーションを実行することはありません。ただし、CGI スクリプトによって結果をキャッシュするように指示されている (Last-modified または Expires ヘッダーによってゼロ以外の time-to-live を示唆することにより) 場合、プロキシは結果をキャッシュします。
Web サーバーのコンテンツをオーサリングする場合は、コンテンツが逆プロキシからも提供されることに注意してください。したがって、Web サーバー上のファイルに対するすべてのリンクを、相対リンクにする必要があります。HTML ファイルでは、ホスト名を参照しないでください。すべてのリンクを次のページのものにする必要があります。
/abc/def
この場合の完全修飾ホスト名は次のとおりです。
http://http.site.com/abc/def
逆プロキシモードで発生するエラーのカスタムエラーページを指定できます。これらのエラーページは、プロキシによって生成されるエラーより優先されます。これにより、クライアントから、Proxy Server が設定されていることがわからないようにすることができます。
セキュリティー保護された逆プロキシを設定する前に、デジタル署名、認証局 (Certificate Authority、ACA)、および認証についてよく理解しておく必要があります。
セキュリティー保護された逆プロキシの設定は、セキュリティー保護されていない逆プロキシの設定とほぼ同じです。唯一異なる点は、暗号化するファイルのプロトコルとして HTTPS を指定する必要があるということだけです。
次の手順に、ユーザーが選択する設定シナリオに応じた、セキュリティー保護された逆プロキシの設定方法を説明します。マッピングの設定方法を説明するために、ここでは、http.site.com という Web サーバーがあり、proxy.site.com というセキュリティー保護された逆プロキシを設定する場合を考えてみます。手順を実際に実行する場合は、下記の例で使用されている名前を、実際の Web サーバー名とプロキシ名に置き換えてください。
サーバーマネージャーにアクセスし、「URLs」タブをクリックします。
「Create Mapping」リンクをクリックします。
「Create Mapping」ページが表示されます。
表示されたページで、次の方法に従って通常マッピングと逆マッピングを設定します。
「Regular mapping」:
「Source prefix」: https://proxy.mysite.com
「Source destination」: http://http.mysite.com/
「Reverse mapping」:
「Source prefix」: http://http.mysite.com/
「Source destination」: https://proxy.mysite.com/
変更を保存して適用します。
作成したマッピングを表示するには、「View/Edit Mappings」リンクをクリックします。
この設定は、プロキシサーバーがセキュリティーモードで実行されている場合にのみ機能します。つまり、暗号化を有効にして、プロキシをコマンド行から再起動する必要があります。プロキシをコマンド行から再起動するには、プロキシディレクトリに移動して ./start と入力します。
サーバーマネージャーにアクセスし、「URLs」タブをクリックします。
「Create Mapping」リンクをクリックします。
「Create Mapping」ページが表示されます。
表示されたページで、次の方法に従って通常マッピングと逆マッピングを設定します。
「Regular mapping」:
「Source prefix」: http://proxy.mysite.com
「Source destination」: https://http.mysite.com/
「Reverse mapping」:
「Source prefix」: https://http.mysite.com/
「Source destination」: http://proxy.mysite.com/
変更を保存して適用します。
作成したマッピングを表示するには、「View/Edit Mappings」というリンクをクリックします。
この設定は、コンテンツサーバーがセキュリティーモードで実行されている場合にのみ機能します。
サーバーマネージャーにアクセスし、「URLs」タブをクリックします。
「Create Mapping」リンクをクリックします。
「Create Mapping」ページが表示されます。
表示されたページで、次の方法に従って通常マッピングと逆マッピングを設定します。
「Regular mapping」:
「Source prefix」: https://proxy.mysite.com
「Source destination」: https://http.mysite.com/
「Reverse mapping」:
「Source prefix」: https://http.mysite.com/
「Source destination」: https://proxy.mysite.com/
変更を保存して適用します。
作成したマッピングを表示するには、「View/Edit Mappings」というリンクをクリックします。
この設定は、プロキシサーバーとコンテンツサーバーがセキュリティーモードで実行されている場合にのみ機能します。つまり、プロキシに対して暗号化を有効にし、プロキシをコマンド行から再起動する必要があります。プロキシをコマンド行から再起動するには、プロキシディレクトリに移動して ./restart と入力します。
プロキシサーバーインスタンスを逆プロキシサーバーとして設定しても、デフォルトでは転送プロキシサーバーとしての機能は停止されません。このようなサーバーインスタンスは、逆プロキシ要求だけでなく、転送プロキシ要求も受け入れてサービスを提供します。転送プロキシ機能を無効にするには、追加の設定が必要になります。URI が転送プロキシ形式と一致する要求を拒否するように、ACL を設定できます。この設定のために、Client 指令を使用できます。
<Client uri="http://.*"> PathCheck fn="check-acl" acl="http://.*" <Client> . . . The "http://.*" ACL can be a deny all ACL as follows: . . acl "http://.*"; deny (all) user="anyone";
仮想マルチホスティングは、配信元サーバー (逆プロキシサーバーなど) が、複数の DNS エイリアスに対して、それぞれのアドレスに別々のサーバーがインストールされているかのように応答できるようにする機能です。例として、次のような DNS ホスト名があるとします。
www
specs
phones
これらのホスト名は、同じ IP アドレス (逆プロキシの IP アドレス) にマッピングされます。次に、アクセスに使用された DNS 名に基づいて、逆プロキシに異なる動作をさせることができます。
仮想マルチホスティングを使用すると、複数の異なるドメインも 1 台の逆プロキシサーバーでホストできるようになります。次に例を示します。
www.domain-1.com
www.domain-2.com
www.domain-3.com
複数のローカルホスト名と複数のドメインの組み合わせを、すべて 1 台のプロキシサーバーに保持できます。
www
specs
phones
www.domain-1.com
www.domain-2.com
www.domain-3.com
仮想マルチホスティング機能は、DNS ホスト名およびドメイン名またはエイリアスを指定して、ターゲット URL のプレフィックスに、そのホスト名に送信された要求が送られる場所を指定することによって機能します。例として、次の 2 つのマッピングがあるとします。
engr.domain.com -> http://int-engr.domain.com
mktg.domain.com -> http://int-mktg.domain.com
マッピングはルート対ルートで行う必要はありません。ターゲット URL 内に URL パスのプレフィックスを追加することもできます。
engr.domain.com -> http://internal.domain.com/engr
mktg.domain.com -> http://internal.domain.com/mktg
仮想ドメインのマッピングにも同じことが当てはまります。たとえば、次のようなマッピングを使用できます。
www.domain-1.com -> http://int-engr.domain.com
www.domain-2.com -> http://int-mktg.domain.com
システムは、HTTP の「Host:ヘッダーを見にいきます。そのヘッダーに基づいて、一致する仮想マルチホスティングのマッピングが選択されます。一致するマルチホスティングのマッピングがない場合、サーバーは、続けて設定ファイルに表示される順にほかのマッピングを見にいきます。一致するものが見つからなければ、マッピングは実行されません。一致するものがない場合、通常、「プロキシは要求の実行を拒否しました」という応答がプロキシから返されます。
サーバーマネージャーにアクセスし、「URLs」タブをクリックします。
「Configure Virtual Multihosting」リンクをクリックします。
「Configure Virtual Multihosting」ページが表示されます。
「Source Hostname (alias)」フィールドで、このマッピングを適用するローカルホスト名 (または DNS エイリアス) を入力します。
「Source Domain Name」フィールドで、このマッピングを適用するローカルドメイン名を入力します。
通常、複数の異なる DNS ドメインをマルチホストする場合を除き、この名前はユーザー自身のネットワークのドメイン名になります。
「Destination URL Prefix」フィールドに、ホスト名とドメイン名が上の指定と一致する場合に要求が送信されるターゲット URL のプレフィックスを入力します。
Iテンプレートを使用している場合は、「Use This Template」ドロップダウンリストからテンプレート名を選択します。テンプレートを適用しない場合は「NONE」のままにします。
[了解]をクリックします。
「Restart Required」をクリックします。
「Apply Changes」ページが表示されます。
「Restart Proxy Server」ボタンをクリックして、変更を適用します。
作成するそれぞれの仮想マルチホスティングのマッピングについて、上記の手順を繰り返します。
仮想マルチホスティングのマッピングはすべて、「Configure Virtual Multihosting」ページの下部に表示されます。「Source Hostname (alias)」と「Source Domain Name」フィールドは、プロキシのポート番号とともに 1 つの正規表現にマージされ、「Host:ヘッダーを見にいきます。
たとえば、ホスト名が www、ドメインが example.com、ポート番号が 8080 の場合、次のような正規表現が表示されます。
www(|.example.com)(|:8080)
これは、ユーザーが入力するか、クライアントが送信する、次のようなすべての組み合わせと必ず一致します。ポート番号は、80 以外の場合でも、サーバーがそのポートで待機していたため、クライアントソフトウェアによって省略されることがあります。
www
www:8080
www.example.com
www.example.com:8080
逆プロキシのマッピングを設定する前には、クライアント自動設定機能を無効にする必要があります。クライアント自動設定機能は転送プロキシを対象としており、逆プロキシは対象としていません。
仮想マルチホスティング機能により、自動逆マッピングが設定されます。「Virtual Multihosting」ページを使用して指定したマッピングに対して、逆マッピングを作成しないでください。
仮想マッピングは、obj.conf 内で virt-map 関数を使用して指定します。
仮想マッピングは、 obj.conf 設定ファイル内で指定された順にマッチングされます。仮想マッピングを行う前に、通常マッピング、逆マッピング、正規表現によるマッピング、またはクライアント自動設定によるマッピングが存在する場合、これらが最初に適用されます。同様に、仮想マッピング内に一致するものが存在しない場合、obj.conf 内の仮想マッピングセクションの次にあるマッピングに進んで変換が行われます。
仕様の順序では、逆マッピングを他のマッピングの前に指定する必要があります。
Proxy Server のポート番号が変更された場合、新しいポート番号を反映するため、仮想マルチホスティングのマッピングを再作成する必要があります。