【Squid】リバースプロキシサーバー・SSLアクセラレータのdefaultsiteの挙動について

Squidとは

そういえば、プロキシサーバーや
リバースプロキシってなに？
って聞かれるとイマイチ
はっきり答えられない

意外といろんな仕事をしているので
一概にこれと言えないからなのかも
しれない

例えば
サーバーが複数台あったとして
今どき通信は暗号化されてて当たり前
普通にするとすべてのサーバーに
SSL証明書が必要だけど
いちばん手前にリバースプロキシ
サーバーを置いて、こいつにだけ
SSL証明書を持たせる

いったん通信をすべてリバプロで
受けて各サーバーに振り分け、と
そうすればSSL証明書は
ひとつで済むという話

このSSLアクセラレータという機能が
今回携わった案件
と言ってもリバプロとサーバーが
１対１で、それ意味あるの？
と言えなくもない状態だけど

で、このプロキシやリバースプロキシ
のなかではかなりの確率で
Squidというサービスが仕事をしている

Squid.confの設定

Squidの設定は基本的にConfigファイルを
いじることで行う
もしかしたら使いやすいコンソールなぞ
存在するのだろうか

端的に言うと、リバースプロキシとしての
機能は以下の２行に凝縮されている
と言っても過言ではないと思う

https_port 192.168.0.1:443 accel cert=certificate.pem key=key.pem defaultsite=192.168.0.2 protocol=http
cache_peer 192.168.0.2 parent 80 0 no-query originserver

192.168.0.1の443ポート(https)に対してリクエストがきたら
certとkeyの証明書を使ってhttps通信をしたうえで
192.168.0.2に対して80ポート(http)で転送しなさい

で、defaultsiteがどういう意味かと言うと

httpリクエストにHostがない場合にはホスト名は192.168.0.2にしなさい

という意味

具体的には192.168.0.2サーバーの
環境変数Server_nameにdefaultsiteの
値を代入している

つまり、前回・前々回の記事にも
からむけど、リダイレクト先には

https://[Server_name]/xxx

を返すので
ローカルIPが漏えいする原因となる

転送先の192.168.0.2サーバーの
Apache.confに強制的に
Server_nameの値を入れ込んで
みたところ、やはり通信上
手前にあるSquidが優先されるらしく
対策はdefaultsiteの値をホスト名と
しておくしかないらしい

defaultsiteについてまだまだいろいろ

さて、Squidはhttpsで通信を受けて
httpで転送しました、
が、転送先(192.168.0.2)からSquidに
対する通信をhttpsにする機能は
持ち合わせていない(たぶん)

https(443)の通信しか許可していない
というケースは多いはずだから
このままだとhttpが蹴られてエラーが
発生するのがお約束のコース

なので、どこかでhttpsでSquidに返す
ような仕掛けを作ってあげることが必要

今回の案件ではこともあろうに
スクラッチ開発したアプリ側に
この仕掛けを作ってあった

Server_nameが192.168.0.xxx
(ぜんぜん関係ないアドレスだけど
Squid.confのdefaultsiteと一致)
だったらhttpsで返すという設定…

ちゃんと動いている間はよかったけど
リバースプロキシを入れ替えた際に
問題が発生、アプリ様がhttpsを
返さなくなる…

なのでアプリ側の設定はとりあえず
たぶんずっと無視してApacheの機能で代用

状況証拠から推察するに
Squid2(2.6)からSquid3(3.5)に
バージョンが上がった際に、
転送先のServe_nameを
Squid.confのdefaultsiteに
書き換えるという挙動が
変更になったと思われる

確認できる限り、
Squid3.5ではServer_nameは
元のまま書き換わっていない

これを示している文献は
見つかっていないが
Squid自体がもともと
http1.0での通信をベースに
作られているということを
鑑みると一定の信憑性はあるかと

この調査だけで2～3ヶ月かかり
自宅のLinuxにもSquidを導入したりで
えらく大変だった、けど
得るものも多かったかもしれない
意図せずして自宅にWebサーバーを
構築できる日も近いかもしれない