プロキシとリバースプロキシ

同じ「プロキシ」という言葉で、話が噛み合わない

プロキシを入れよう、という会話が噛み合わないことがあります。片方は社員の通信を管理する装置を、もう片方はサーバーの前に置く装置を思い浮かべているからです。どちらも通信を中継する点は同じですが、立っている場所が正反対です。

クライアントの代理か、サーバーの代理か

利用者の側に立つほうを、フォワードプロキシと呼びます。

利用者 → フォワードプロキシ → インターネット

出ていく通信をここに集めると、行き先を制限したり、誰がいつどこを見たかを記録したりできます。会社や学校で特定のサイトが開けないのは、たいていこれです。出す側から見れば、自分の代わりに外へ行ってくれる係です。

サーバーの側に立つほうを、リバースプロキシと呼びます。

インターネット → リバースプロキシ → 裏のサーバー群

外から見ると、こちらがサーバー本体に見えます。裏に何台いるか、どんな構成かは外に出ません。前回のロードバランサも、実体はこの形の一種です。

守りたい側が逆になっているだけ、と覚えると混乱しません。

1 台しかなくても、前に 1 枚置いておく

サーバーが 1 台しかない構成でも、前にリバースプロキシを置くのが定番です。無駄に見えますが、後から欲しくなるものがだいたいここに乗るからです。

証明書の扱いをここにまとめれば、アプリは平文の HTTP だけ考えればよくなります。アクセスの記録も、画像や CSS を返す仕事も、アプリの手前で終わらせられます。台数を増やしたくなったときも、振り分け先を書き足すだけで済みます。

逆に、アプリに直接 443 番を向けてしまうと、これらを足すたびに構成そのものを組み替えることになります。最初の 1 枚は、拡張のための入口を確保しておく作業です。

置いた瞬間に 1 つ壊れるものがあります。送信元の IP アドレスです。中継しているのはプロキシなので、アプリから見える接続元は全部プロキシになります。アクセス制限も、回数制限も、記録も、全員が同じ相手に見えて機能しません。

対策は決まっていて、プロキシが元の IP をヘッダー (X-Forwarded-For がよく使われます) に書き足し、アプリはそちらを読みます。ただしヘッダーは送る側が自由に書けるので、外から来た値をそのまま信じてはいけません。自分のプロキシが付けた分だけを採用する、という設定が要ります。ここを省くと、制限を外したい人が好きな IP を名乗れます。

中継はできても、中身は読めない

フォワードプロキシで HTTPS を扱うときは、制約があります。中継はできても、中身は暗号化されていて読めません。

このときプロキシは、CONNECT という専用の依頼を受け取り、指定された相手との間に単なる通り道を用意します。プロキシに見えるのは接続先のホスト名くらいで、どのページを見たかまでは分かりません。

中身まで検査したいなら、プロキシがいったん暗号を解いて読み、もう一度暗号化して送り直すしかありません。そのためには、プロキシが発行した証明書を全端末に信頼させる必要があります。技術的には可能ですが、端末を管理下に置けることが前提になるので、社内の端末以外には持ち込めません。