>>324
その方法だと、ソース・アドレスがxinetdを走らせているマシンのものに変わっ
てしまうので、proxy規制系の変更が必要になるのでは？

66では、「第2案だとproxy規制系の変更がいらない」とあるが、これは勘違いで
「第1案でも第2案でもproxy規制系の変更がいる」だと思われ。

もっとも、transparent proxyと併用すれば、(第1案、第2案とも) proxy 規制
系の変更なしに実施できるが、フリーなOSでの transparent proxyの利用に関
する資料ってあんまりみたことない。UNIX Magazine で、ちらっと見たことあ
るぐらいだし、その記事のやり方だとソースアドレスが変わっちゃうので
proxy規制の変更を避けるという目的には使えない。proxy規制の変更を避けた
いなら、カーネルだけではなく、アプリケーション側にも若干手を入れる必要
がある。変更量自体はわずかなんだけど、今の2chの運用状況を見る限り、
ここまでするのは、ちょっと荷が重い気がする。

proxy規制系に手を入れない、かつ、WWWサーバー側ではなくfirewallで対処す
るというのなら、商用firewall(の中で syn flood 対策面での性能の高い奴)を
入れるというほうが金はかかるが実現可能性は高いんじゃないか。