「通常のプロキシのほうはだいたいおぼえた」
「リバースプロキシを活用してリダイレクトを構成したい」
今回は、そのような方に向けた記事となります。
リバースプロキシの役割
リバースプロキシは、クライアントとWebサーバーの間に配置します。
オリジンサーバーを含めた位置関係
それぞれの位置関係は、
「クライアント」 – 「リバースプロキシ」 – 「Webサーバー（オリジンサーバー）」
となります。
クライアントからのリクエストは、オリジンサーバーではなく、まずはリバースプロキシへと送られ、リバースプロキシが窓口となってオリジンサーバーへ取り次ぐ形となります。
これにより、オリジンサーバーをクライアントに対して秘匿しながらも、クライアントに対してコンテンツを公開できている状態が実現可能となります。
リバースプロキシが配置されている場合、コンテンツが置いてあるWebサーバーのことをオリジンサーバー（Origin Server）と呼びます。
オリジンサーバーの数は1つとは限らず、複数設置したうえで、リバースプロキシによる振り分けが可能です。
リバースプロキシによる複数のオリジンサーバーへの振り分けなどについては、当ブログ内の関連記事も参照してください。
リバースプロキシサーバーが配置されていることにより、クライアントからのすべての要求に対する直接的な対応は、オリジンサーバーの代わりにリバースプロキシサーバーがおこないます。
オリジンサーバーが複数用意されている場合は、クライアントからのリクエストは、振り分けルールどおりにそれぞれのオリジンサーバーへと振り分けられます。
（上記の「振り分けルール」は、リバースプロキシサーバーの管理者による設定にもとづきます）
なぜオリジンサーバーを複数用意する場合があるのか
リバースプロキシを配置する場合、オリジンサーバーは必ず1つ以上配置されます。
・クライアントからのアクセスを振り分けることで負荷分散する
・コンテンツをミラーリングし、片方のサーバーがメンテナンス中でもクライアントへのサービスを止めることなく稼働させるため
・異なるシステムで稼働しているそれぞれのコンテンツを別サーバーに配置する
・複数の外部企業によって自社へと提供されているコンテンツのメンテナンス時に、外部企業Aが外部企業Bのコンテンツにアクセスしてしまうような事故を物理的に防止するためサーバーを分ける
などの目的があります。
明示型プロキシと透過型プロキシとの違いは？
明示型プロキシと透過型プロキシの違いや、それぞれのメリット・デメリットについて説明します。
明示型プロキシ（Explicit proxy）
Explicitモードとも呼ばれる。（Explicitとは、「明示的な」という意味）
クライアント端末側で明示的にプロキシアドレスを指定する必要がある。
明示型プロキシのメリット
・構成がシンプルであること
明示型プロキシのデメリット
・クライアントの端末側でのプロキシアドレス設定が必要なため、大人数の社員用PCなどに設定するのは手間がかかる
透過型プロキシ（Transparent proxy）
Transparentモードとも呼ばれる。（Transparentとは、「透明」という意味）
クライアント端末側での設定は不要。クライアント側から見た場合、普通に直接インターネットに接続しているように見えるが、実際には「ブリッジとして通信の途中に組み込まれているプロキシ」を経由したアクセスとなる。
透過型プロキシのメリット
・クライアントの端末側でのプロキシアドレス設定が不要。このおかげで、クライアントの端末数が多くても設定の手間じたいはかからない
透過型プロキシのデメリット
・使用するプロキシによっては透過型に非対応の場合がある（squidやBluecoatは対応OK。i-filterにも透過型プロキシ機能あり）
・ブラウザやウィルス対策ソフトによる警告が表示される場合がある（実際には有害ではない構成であったとしても、httpsなどで、SSL/TLSの警告が出てしまう場合がある）。
サーバ側とクライアント側それぞれに設定が必要です。
サーバ側での設定：プロキシサーバ側にて、動的に各サーバへの証明書を作成（たとえば、クライアントがwww.hogehoge.co.jp へアクセスする際には CN=www.hogehige.co.jp の証明書をその場で作成しクライアント側へと提示する）
CNとは：
CN（Common Name）。コモンネームは、SSLサーバー証明書の設定項目のひとつ。SSLによる暗号化通信を対象としたサイトURLの、サブドメインまでを含んだドメイン部分のことです。
コモンネームの例：
URL が https://jp.hogehoge.com/company/guideline.html
の場合のコモンネームは jp.hogehoge.com
URLが https://105.xxx.yyy.168
の場合のコモンネームは 105.xxx.yyy.168
SSLによる暗号化通信をおこなう際、ブラウザはアクセス先のURLと証明書のCNが一致しているかどうかをチェックしているため、それぞれを一致させる必要があります。
（同一ドメイン内に、サブドメインが複数ある場合は、ワイルドカード「*」を使用して部分一致による証明書の発行が可能な場合もあります）
クライアント側での設定：信頼設定をする必要がある。具体的には、上記のサーバーのルート証明書のインストールをおこなう。
・事前にPBRの設計が必要となり、ネットワーク構成が複雑になってしまう
PBR（Policy-Based Routing）は、パケットの転送を管理者による設定（ポリシー）にもとづいて
おこなうこと。また、その技術を指します。route-mapコマンドによって定義されます。
おもな設定項目は、「入力インターフェイス、アドレス、プロトコル、ポート番号、パケットサイズ」などです。
管理者がおこなう作業としては、PBR設定が可能なネットワーク機器の選定や、その経路付近にプロキシサーバーを設置可能かの確認が必要となります。
リダイレクトにおける注意点
リダイレクトをおこなう際は、不正なリダイレクトにならないように留意する必要があります。
不正なリダイレクトを避けよう
不正なリダイレクトはユーザーに迷惑をかけ、Googleからのペナルティも受けてしまいます。
不正なリダイレクトの例としては、以下のようなものがあります。
・検索エンジンのクローラーからのリクエストに対しては通常のサイトで応答されるが、人間がブラウザを使ってアクセスした場合には、まったく違うスパムサイトへとリダイレクトされる
・クライアントの使用している端末がPCの場合には通常のサイトが表示されるが、スマートフォンからのアクセスの場合にはスパムサイトへとリダイレクトされる
などの例があります。
このような不正なリダイレクトをした場合、Googleからペナルティを受けて検索結果上の順位が下がったり、最悪のケースでは検索結果から除外される場合もあります。
PCサイトとスマホサイトで厳密にレイアウトを分けたい場合などに、サイト内容が同一でレイアウトの異なるサイト（同一ドメイン内）へとそれぞれリダイレクトするような使い方であれば、不正なリダイレクトとはみなされないでしょう。
不正なリダイレクトはせず、あくまでユーザーの利便性を高めるためにリダイレクトを活用していきましょう。
あわせて読みたい記事
（ここでは、オリジナルのコンテンツが存在するWebサーバーのこと。リバースプロキシサーバーの存在により、クライアントのダイレクトアクセスから保護される）