多段プロキシ

今日、別チームのエンジニアさんからお客さんところで使っているプロキシサーバがらみの相談がありました。使っているのはSquidでaccess.log（今回はすべてのログではなくgrepコマンドを使って特定のIPが含まれる通信を抜粋した状態）で見せてもらいました。

検証環境では問題がないので、その問題がないログと見比べていました。どうもまだお客さんところの環境について詳しく聞けてないようですが、http://squid.robata.org/faq_6.html　などをみるとうまくいってないときのログは「親のプロキシとの通信」に関連したログになっていました。そっか、多段プロキシ構成か・・・、とりあえず切り分けの結果、お客さんには親プロキシを確認してもらう、ということで一次回答のようです。

ぢろーらもも動作検証のためにSquidをたてることはあります。まあ、ほとんどの場合は基本的な構成のみです。インストール、設定に関してGoogle使えば割と簡単に情報が手に入ります。たとえば、http://www.stackasterisk.jp/tech/systemConstruction/squidSat01_01.jsp;jsessionid=a0r-0XhIMo0a　あたりはわかりやすいです。

あとやったことがあるのは透過型プロキシ。こちらはクライアントのゲートウェイがプロキシになるように設定します。動作としては、クライアントからの宛先IPアドレスはそのままで、MACアドレスのみプロキシのものになります。この場合、クライアントのWebブラウザにプロキシ設定をしなくてもよい、という利点があります。（参考サイト：http://www.stackasterisk.jp/tech/systemManagement/squidStat01_01.jsp）

多段プロキシは構築したことないなぁ・・・。お客さんの環境でお目にかかったことはありますが。

で、調べてみました。http://squid.robata.org/build_hierarchy.html　などを参考にするかぎり、そんなに設定としては難しくはなさそうです。親子関係（parent）のときは、親に問い合わせてキャッシュがない場合には親が実サーバにとりに行く、sibling（兄弟）関係のときは、兄弟に問い合わせてキャッシュがない場合には自分で実サーバにとりに行くのですね、なるほど…。

まあ、設計についてはイメージはできました。
ただ、いまいちピンとこないのは「なぜ多段にするか？」です。みなさんおっしゃっているように、多段にすると経由する機器増えるわけですし、当然パフォーマンスは落ちます。
1つの利点として「匿名性をあげる」というのがありますが、それって悪いことをするため？
結局ISPとかにはしっかりログあるわけですし、手間が増えるってだけで、２ちゃんとかに殺害予告なんかした日には普通に逮捕されると思っていたほうがいいでしょう。

あとは、プロキシ毎にセキュリティをかけられるから、セキュリティ強化という意味もあります。
コストや性能との兼ね合いではありますが、要件によってはありかと思います。

あ、もっといい例がありました。
http://www.macnica.net/lanch/lanch76/sp01.html/

複数拠点をもつ会社さんで、セキュリティ上、インターネットへの出口を一か所にするため、必ず本社を経由させたい、という要件がはいる場合はけっこうあります。ただ、これだとウィルスのパターンファイルとかOSパッチなんかのダウンロードが集中したときに本社の回線を圧迫してしまうことになります。
そのようなトラフィックは支社から直接送り出し、それ以外のトラフィックは本社経由にするといった制御を、多段プロキシ構成で実現するわけです。これのほうがスマートな感じはします。

そういえば、ぢろーらもがまだエンジニアになりたての頃、多段プロキシ構成で苦い思い出があります。とあるソフトがログに記録されるX-forwarded-For（もとのクライアントのIP情報）をもとにクライアントIPをレポーティングする仕様になっていたのですが、多段プロキシ構成で途中のプロキシがX-forwarded-Forアドレスを正しく読み込めず、不正なIPとみなされてしまう現象がありました。普通に考えると、途中のSquidかなにかがX-Forward-Forを先に渡さないようにパラメータが設定されてた、とかそんな感じでしょうかね。

まあ、わかってしまえばどうということはないのですが、この原因が判明するまで相当な時間を要してしまいました。すでにパケットキャプチャはもらっていたのですが、このときのぢろーらもはEthereal(現：WireShark）のようなツールの存在も知らず、まったく手がでませんでした。
結局このときは別会社でエンジニアの経験が長かった同僚に解決してもらいました。

このとき彼が行なった作業ですが、彼は「にらめっこ」と表現していました。要するに、Ethereal使ってとったキャプチャデータにIPアドレスなどでフィルタかけて、関連したIPのパケットだけもってきたうえで、テキストファイルに関連する情報を吐き出し、それを注意深くずっと眺めていて原因究明にいたった、というわけです。思ったよりも泥臭い作業ですが、これが大事です。

その後ぢろーらもも、少しずつこういった作業を覚え、成長していった（？）のでありました「(^^;)。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---