おもちゃ箱ブログのアクセス解析 5月 ： IT編

さきほどの「おもちゃ箱ブログのアクセス解析　5月」続きでございます。こちらはIT編。これらに関しては、こういう情報を求めている人になんらかのヒントになればいいかな、と思って書いています。

「cn コモンネーム ワイルドカード文字 rfc」

　最終的に何を調べたかったのかはわかりませんが、お役に立てたでしょうか？確かにRFCの部分では「仮想サイトの場合には証明書を提供する段階ではどのサイトにアクセスされたのかわからないので、SSLパケット上にホスト名がわかるような情報を載せる」というところでRFCの話題をだしました。

「x-forwarded-for 多段プロキシ」

　おっと、これは以前の「多段プロキシ」の記述がちょっとに違ってましたね・・・。多段プロキシの場合、前段のプロキシがX-Forwwarded-Forをoffにしてしまうと、その先のプロキシではX-Forwarded-Forが読み取れず、もとのクライアントのIPがわからなくなります。もとのクライアントのIPを隠ぺいできる、というのはセキュリティ上のメリットにはなるのでしょうが、当時はそれが裏目にでてしまいました。

「マルチホーミング　dns　インバウンド　自宅」

　自宅で、ですか・・・・。ちょっとわたくしも調べてみましたが、http://princo.org/tips/iproute2.html　http://flatray.com/linux/multihome/　などに紹介されているように、Linuxにインストールできるパッケージのiproute2を駆使して、一応構成はできるみたいですね。アウトバウンドの通信についてラウンドロビン的な振り分けができたり、WAN側からはいってきたリクエストに対する応答を、もとの回線に戻すこともできるようです。DNSの部分は本当は回線に障害があった場合がその回線に紐づいたAレコードは返さないようにしたいところですが、Webとかの通信であれば名前解決の部分は単純なDNSラウンドロビンだけにしても、IEとかだと障害時もうまく処理してくれるようです。なので、アプリケーションによってはどうにかなるかもしれません。

　この構成の制限としては、http://flatray.com/linux/multihome/　でも触れられているように、回線の障害監視まではできないこと、あとはアウトバウンド通信時にクライアントIPアドレスに基づいた接続維持（同じクライアントからの通信は宛先にかかわらず一定時間は同じ回線を使い続ける）がないので、一部のサイトに関しては複数のセッションが別の回線から出てしまうことで弊害が起きることはあるようです。

　もちろんカスタマイズできるのであればそれでクリアできるのでしょうけど、簡単に行うとなるとやはり市販のマルチホーミング機器になるのかな、と思います。http://japan.zdnet.com/release/story/0,3800075480,10024926,00.htm　にもあるように、一番ローエンドなものでも３０万円近くはするので、一般家庭にいれるには高価なものですわね。

「Active-Active　ファイアウォール　構成例」

　こちらはどういうわけか、たまたま別の記事に書いていたそれぞれの語句でマッチングしてgoogleにひっかかりました。なので、おそらく検索された方の目的は達成されなかったことかと思います。

　たとえば、比較的一般的かな、と思うのは、VRRPグループを複数持てるようなファイアウォールを使って、半分のクライアントにはVRRP１側のデフォルトゲートウェイ、もう半分はVRRP2側のデフォルトゲートウェイを設定する、という方法です。発想としてはシンプルかと思いますが、クライアントに別の設定をするのは面倒かもしれませんね。たとえばこのサイト：http://www.furukawa.co.jp/fitelnet/product/f100/setting/detail/vrrp2.html　まあ、ルータではありますけど、考え方はいっしょです。

　あとは、ファイアウォールをロードバランサで負荷分散する、という手もあります。「ファイアウォール　負荷分散」で検索すると、Radware、Nortel（といっても、L4/L7部門はRadwareに買われてしまったので、結局は「Radware」ですが）、PIOLINKといったメーカーがマッチします。行きと帰りの通信を同じファイアウォールに戻すために、バランサはファイアウォールの上下でサンドウィッチにします。

　けっこうお金のかかりそうな構成なのですが、負荷が増えたら並列にファイアウォールを増やせばいいので、ファイアウォールのリプレイスをするよりも簡単でコストも少ない場合もあります。もちろん、バランサがボトルネックになっては本末転倒なのでバランサにもそれなりのスペックは必要です。ただ、ファイアウォールといっても純粋にファイアウォールの役割だけさせるのであればけっこうスループット高くても、IPSとかアンチウィルスみたいな高度な処理をさせるとなるとスループットはガクンと落ちるはずです。そういう場合には、ファイアウォールのスケールアップで対応しようとするとコストがかさんでしまうので、このソリューションも有効かもしれませんね。

　あとは、http://www.atmarkit.co.jp/fsecurity/special/12fire/fire01a.html　で「自律型」と称されているように、ファイアウォール自身で互いのセッション管理をしてうまく振り分ける、という方法を実現しているものもあります。まあ、このあたりはCheck PointのIPシリーズ（旧NOKIA製品)のIPクラスタリングなどのようにメーカー独自の方法なのかと思います（参考サイト：http://www.asgent.co.jp/Products/CP_IP/ip_point.html　など）。

　

　まあ、こんな感じで自分の勉強にもなりました。こういう作業を続けると、サイトの内容を工夫するヒントが得られそうです。もうちょっと頑張ってみます。

---

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

---