コンピューターシステム株式会社

技術BLOG

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

ネットワーク 2019/11/15 大阪担当

おはこんばんちわ。大阪営業所のこばこばさんです。

今回はリバースプロキシについて紹介します。

リバースプロキシ(英: Reverse proxy)または逆プロキシとも呼びますが

一言でいうと外部(インターネット等)からのアクセスをWebサーバの代理としてに受け付け

アクセス応答をクライアントPCへ返すサーバーとなります。

リバースではない通常のプロキシサーバは一般的に社内ネットワークの出入り口に設置され

クライアントPCの代理として外部Webサーバへアクセスするサーバーとなります。

文章で説明しても「なんのこっちゃ」となるので、

筆者自身の復習も兼ねてプロキシ・リバースプロキシそれぞれの構成・利点など図解もまじえて紹介していきます。

まずプロキシサーバーは以下図のように、クライアントPCとアクセス先のWEBサーバーの間に配置されたサーバーとなり

「クライアント側のリクエスト要求を代理する」サーバーとなります。

プロキシ構成の利点

・プロキシサーバでユーザー認証する事により社内ネットワークからインターネットへの不正アクセス防止が可能。

・プロキシサーバで通信ログを取得する事で通信の一括監視が可能。

・プロキシサーバでパケットフィルタリングを行う事で不要な通信の除外が可能。

・プロキシサーバで有害サイトのURL制限を行う事でアクセス制限が可能。

・プロキシサーバが代理で通信する事で、クライアントPCの固有情報(IP、OS、ブラウザ情報など)を隠蔽する事が可能。

※プロキシサーバー自体の固有情報は伝わります。

・プロキシサーバで通信のキャッシュを行う事でトラフィックの削減が可能。

プロキシ構成の欠点

・プロキシサーバーに大量のアクセスが集中すると、通信速度の低下を招く

・プロキシサーバーがダウンするとインターネット通信が出来なくなってしまう

・プロキシサーバーの管理コストがかかってしまう

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

リバースプロキシサーバーも同様に、クライアントPCとアクセス先のWEBサーバーの間に配置されたサーバーとなりますが

設置場所が違い、「アクセス先WEBサイト側の拠点」に設置され

「WEBサイト側のリクエスト受付を代理する」サーバーとなります。

一言で言うとプロキシサーバーは「クライアント側のリクエスト要求を代理する」サーバ

リバースプロキシサーバーは「WEBサイト側へのリクエスト受付を代理する」サーバーとなります。

若干言葉遊びのような説明になってしまいましたが、以下図の通り、リバースプロキシサーバーは

WEBサーバー側環境に設置され、WEBサーバーへのアクセスを代理で一手に引き受ける形になります。

リバースプロキシ構成の利点

・リバースプロキシサーバーがインターネットからの通信を一手に引き受ける為、

 Webサーバへの直アクセスが不可となりWebサーバの情報漏えい防止が可能。

・リバースプロキシサーバーを使用し,SSLの処理を別のマシンですれば,Webサーバの負荷分散が可能。

・クライアントに影響を与えないで,Webサーバの分割が可能。

・リバースプロキシでフィルタリング設定する事で、特定のIPアドレスのみアクセスを許可したり

 逆に悪意のあるホストからのアクセスを遮断することが出来る。

 ※WEBサーバー単位に設定する必要がなく、セイキュリティ集約が可能。

・URL書き換えにより柔軟なネットワーク構成が可能

 (例: リバースプロキシサーバのバックに配置した複数のサーバにリクエストを振り分ける事が可能)

リバースプロキシ構成の欠点

・リバースプロキシサーバーに大量のアクセスが集中すると、通信速度の低下を招く

※例:上記イメージでWEBサーバーAへアクセスが増大すると、アクセス負荷の低いWEBサーバーBも通信速度が低下してしまう。

・リバースプロキシサーバーがダウンするとクライアントからアクセス出来なくなってしまう

・リバースプロキシサーバーの管理コストがかかってしまう

まずはプロキシおよびリバースプロキシの構成、利点欠点などについて紹介しました。

つづいてはリバースプロキシの設定方法について紹介します。

サンプルとして以下構成を想定し、リバースプロキシ設定を行いました。

上記設定を行う事で、クライアントPC⇔aaa.com(リバースプロキシ)はSSL通信を行いますが

aaa.com(リバースプロキシ)⇔ローカルに構築したkestrelサーバー(127.0.0.1:5000)間は通常のhttp通信を行う形となります。

上記構成ではSSLの暗号化負荷はApache側で処理されるので、APサーバーはSSLの暗号化負荷がかかりません。

またインターネットからのアクセスはリバースプロキシが代理でアクセスするため、直接APサーバーがインターネットにさらされる事もありません。

このような構成にしておけば、以下の様に改変を加える場合も影響が少なくなります。

このようにリバースプロキシ構成にしておけば、通信負荷の増大などで

サーバー構成の変更が必要になった場合にも、柔軟に対応する事が可能となります。

また、リバースプロキシを使用する事で

CSSやJS、画像のような静的なファイルをリバースプロキシ側で配信させ

アプリケーションサーバの負荷を減らしレスポンスタイムを小さくする事もできます。

リバースプロキシでHTTPヘッダのUser-AgentやIPアドレスをチェックする事で

迷惑行為を行うアクセス元に対してアクセスさせない事もできます。

アプリケーションサーバの前段のロードバランサとして使用する事

パフォーマンスを向上させたり、システム全体の運用効率を上げたりすることもできます。

ただし想定する通信量やアクセス数が低かったり、システム処理が単純でレスポンスなどに困っていないなら、

リバースプロキシの導入は必須というわけではない為、不要に導入するといらぬコストがかかってしまう事もありえるので

導入に関しては多方面での検討が必要になります。

まとめ

このようにリバースプロキシ構成にすると冗長化や負荷分散、セキュリティの向上、サーバー構成の柔軟化

運用性の向上など利点がいくつもありますが、全てにおいて無くてはならない物という訳では無く

コストを掛けたくないミニマムな構成を望む場合は逆に不要な物となってしまいます。

「必要な場所に、必要な技術を」といった事もあり

何かを検討する際に、提案材料の一つとして理解しておくことが重要と考えました。

ご紹介は以上となります。なにかの参考にして頂けたら幸いです。

ありがとうございました。