Snap.Shot.cx

[LinuxApps] transproxyで勝手にproxy
05/20/2000 18:18 (投稿者:たかの)

昔、某ISPに勤めていた頃の話。帯域の圧迫に悩む上司が、「あぁ〜、強制的にproxy(cache)サーバを使わせるような仕掛けってないかな〜」と悩んでいた。
「そんなものあるわけないでしょう」って当時の俺は答えたのだけど、ところがどっこい、今はそれができるのだ。

仕掛けはLinuxカーネルの「transparent proxy(透過型プロクシ)」という機能。これはルータとして機能しているLinuxなら利用できる。つまり、内部ネットワークから任意のhttp(port#80)に向かって出るtcpパケットを、すべてローカルの別ポートにredirectしてしまう機能だ。

やり方はこう。
まず、「transparent proxy」を有効にしてカーネルを再構築。
続いて、ipchainsを使って、リダイレクトの設定を行う。こんな感じ。

# ipchains -A input -p tcp -d localhost 80 -j ACCEPT
# ipchains -A input -p tcp -d 192.168.1.0/24 80 -j ACCEPT
# ipchains -A input -p tcp -s 192.168.1.0/24 -d 0/0 80 -j REDIRECT 81

アタマのふたつは、ローカルネットに属するhttpに関してはリダイレクトせずに本来のポートを見なさいという設定。
キモは最後の行。これは、任意のポートに出ていこうとするhttpリクエストを、そのマシン(Linux BOX)の81番にリダイレクトしてしまおうという指定。

もちろん、81番ポートには受けるためのdaemonが必要になる。ここで大事なのが、直接squidなどのキャッシュサーバに渡してはいけないということだ。
なぜかというと、出ていこうとするHTTPリクエストは本来のホストに繋ぎにいこうとしているから、「どのホストにリクエストをかけるか」なんて情報は載せていない。このリクエストを、proxy用のリクエストに変換してやる必要がある。
これをやるのが、transproxyというツール。これを書いている時点での最新版は1.2だ。
http://www.transproxy.nlc.net.au/

コンパイルしたら、任意の場所に置いておく。もともとのドキュメントではinetd経由での起動を推奨しているけど、これはあまりお勧めしない。なぜかというと、httpリクエストってやつは負荷がかかりやすい傾向にあるから、inetdではとてもさばききれないからだ。
tcpserverを使おう。tcpserverはqmailの補助パッケージとして配布されている。解説は滝澤さんの記事を参照のこと。

http://www.ne.jp/asahi/cyber/taki/djb/tcpserver/

実際にはこう使う。

# tcpserver -u 99 -g 99 192.168.1.100 81 /usr/sbin/tproxyd localhost 8080 &

-u 99と-g 99はnobody,nogroupのuid,gidだ。
続く192.168.1.100はLinux Boxの「内側の」IPアドレスを指定する。こうしないと81番ポートのリクエストを外部からも受け付けてしまうことになるので、あまりよろしくない。
81は、もちろんtransproxyを受け付けるポート番号。
そして最後に、transproxyデーモンの起動コマンドと、リダイレクト先(これはsquidなどのproxyサーバのhost,port)を指定する。

これで、内部ネットワークからのhttpリクエストは、すべてLinux BOXのプロクシ経由で接続するようになる。

最後に注意点をいくつか。

1) Linux Box自身はポートリダイレクトの対象とならない。だからたとえば、Linux Boxからネスケを起動した場合は、transparent proxyは有効にならず、直接接続しにいってしまう。
2) proxyとしては、内部ネットワークのサーバを指定しないこと。1)とも関連するが、Linux Box上のsquidが直接接続できれば問題ないが、内部サーバにリダイレクトしてしまうと、ポート80番のピンポンになってしまうので恐ろしいことになる(ような気がする)。必要な場合は、ipchainsの設定を追加して、squidが動いているマシンをREDIRECTから除外するべし。
3) proxyとして使うマシンは十分なパワーを持ったものを使うこと。proxyのボトルネックは、proxyにかかる負荷そのものだからだ。
4) もちろん内部ネットワークからは、外部ホストのDNSが解決できなくてはいけない。

proxyにかかる負荷を考えると、100人以上の中規模ネットワークでの利用はあまりお勧めしない(負荷をうまく分散させるだけのウデがあれば別)。
でも、これをやっておけば、ブラウザでproxy設定の手間が省けるし、proxyの存在や利点を知らない人でさえも、proxyの恩恵にあずかることができる。

あ、間違ってもリダイレクト先を「大阪弁プロクシ」「熊本弁プロクシ」などに繋いではいけない。マジで。

メールでコメント


(Powered by Zope)
リンクはご自由にどうぞ。各記事には記事番号がついていますので、URLは変わりません。
© 2000-2013 Yukimasa TAKANO, all RIGHTs reserved.