リバースプロキシについて

 前回前々回とMXレコードについて書きました。最近話題(炎上?)になっているDNSブロッキングのこともありますので、このあたりにつきましても改めて書いてみる予定です。
 
 今回はDNSからは離れて、リバースプロキシについて書きます。プロキシサーバと言うと、LAN内からWebアクセスするのに使用するサーバとして語られることが多いです。アウトバウンドトラフィックですね。この場合のプロキシサーバをフォワードプロキシと表現することがあります。

 「フォワードがあるのなら、リバースもあるのではないか?」と考える方もおられるかと思います。リバースプロキシと呼ばれるサーバは存在します。
 フォワードプロキシがアウトバウンドトラフィックであるのに対し、リバースプロキシはインバウンドトラフィックです。
 たとえば、https://www.example.jp/ というWebサイトがあるとします。外部のクライアントはブラウザで上記サイトを指定します。普通はwww.example.jpというサーバに直接接続します。
 この場合、www.example.jpが接続要求を受けて、別のサーバからコンテンツを取ってきます。以下のようなイメージです。

[クライアントA] —> [リバースプロキシサーバB] —> [WebサーバC]
https://www.example.jp/ http://data.example.jp/
|<---- https --------->||<---------- http --------->|

 ここではリバースプロキシサーバBがhttpsになっていますが、ここはhttpでも構いません。
クライアントAがhttps://www.example.jp/ にアクセスするために、リバースプロキシサーバBに接続しに行きます。
 しかし、リバースプロキシサーバBはコンテンツを持っていません。そこで、クライアントAから受けたコンテンツ要求をWebサーバCに取りに行きます。そして、WebサーバCから取ってきたコンテンツをクライアントAに返します。これがリバースプロキシの仕組みです。
 NATと異なるのは、TCPコネクションがクライアントAとリバースプロキシサーバB、リバースプロキシサーバBとWebサーバCの2つに分かれていることです。そして、限られた形での中継(プロキシ)を行うことにより、セキュリティも確保出来ます。
 セキュリティ面を考慮して、リバースプロキシサーバBをDMZに設置し、WebサーバCを別のDMZに設置して、リバースプロキシサーバB→WebサーバC方向のみのアクセスを許可するようにすることが望ましいです。
 
 この形ですが、SSLアクセラレータとしての機能もあります。SSL暗号化/復号処理をハードウェア処理させることで、Webサーバの負荷軽減につなげることもあります。
リバースプロキシについて

  • このエントリーをはてなブックマークに追加

コメントをどうぞ