[debian-users:28166] Re: masq したローカルネットワークから不定期に外に出られなくなる

[wada@xxxxxxxxxxxxxxx]

和田です. 

From: Hiroyuki Shimada <shimaden@xxxxxxxxx>
Subject: [debian-users:28163] Re: masq したローカルネットワークから不定期に外に出られなくなる
Date: Wed, 25 Apr 2001 00:48:52 +0900

> On Tue, 24 Apr 2001 11:33:07 +0900
> wada@xxxxxxxxxxxxxxx wrote:
> 
> > kernel-source-2.2.19-2 をコンパイルして作った kernel-image で 
> > masquerade しているのですが, 不定期にローカル側のネットワークが死ぬよ
> > うになりました. 原因は不明なのですが, どうやらローカルネットワークにあ
> > る win98 上で Gnutella の一種の BearShare というソフトをしばらく使うと
> > 駄目になるようです.
> 
> 　関連しそうな設定をしている（わからなければ全部の）ipchains の -l オプ
> ションでログをとってみて、ネットワーク内外のパケットのやり取りの記録から、
> 正常なときと異常なときとの違いを見てみると、わかるかもしれません。

やってみました. まず, 全ての ipchains コマンドにオプション -l をつけた
上で, ネットワークが正常な状態であることを確認してローカル側にある 
win98(192.168.1.4) ユーザに BearShare を動かしてもらいました. その直後
の, ネットワークが正常に動作している時のログは, 例えば以下のような感じ
です.

Apr 25 14:20:03 phys5 kernel: Packet log: forward MASQ eth0 PROTO=17 192.168.1.4:
1270 xxx.xx.xx.35:53 L=63 S=0x00 I=7695 F=0x0000 T=127 (#1)
Apr 25 14:20:03 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
271 206.132.188.135:6346 L=48 S=0x00 I=7951 F=0x4000 T=127 SYN (#1)
Apr 25 14:20:03 phys5 kernel: Packet log: forward MASQ eth0 PROTO=17 192.168.1.4:
1272 xxx.xx.xx.35:53 L=65 S=0x00 I=8207 F=0x0000 T=127 (#1)
Apr 25 14:20:03 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
271 206.132.188.135:6346 L=40 S=0x00 I=8463 F=0x4000 T=127 (#1)
Apr 25 14:20:03 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
271 206.132.188.135:6346 L=62 S=0x00 I=8719 F=0x4000 T=127 (#1)
Apr 25 14:20:03 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
273 64.61.25.139:6346 L=48 S=0x00 I=8975 F=0x4000 T=127 SYN (#1)
Apr 25 14:20:03 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
271 206.132.188.135:6346 L=63 S=0x00 I=9231 F=0x4000 T=127 (#1)
Apr 25 14:20:03 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
271 206.132.188.135:6346 L=204 S=0x00 I=9487 F=0x4000 T=127 (#1)
Apr 25 14:20:04 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
273 64.61.25.139:6346 L=40 S=0x00 I=9743 F=0x4000 T=127 (#1)
Apr 25 14:20:04 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
273 64.61.25.139:6346 L=62 S=0x00 I=9999 F=0x4000 T=127 (#1)


そして, 以下がネットワークが死んだ後のログです.

Apr 25 14:47:40 phys5 kernel: eth1: Transmit timed out, status 0000, PHY status 7
82d, resetting...
Apr 25 14:47:41 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
322 130.65.214.243:6346 L=1500 S=0x00 I=31994 F=0x4000 T=127 (#1)
Apr 25 14:47:41 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
879 64.166.208.133:4096 L=786 S=0x00 I=32250 F=0x4000 T=127 (#1)
Apr 25 14:47:42 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
811 64.229.6.75:6346 L=63 S=0x00 I=32506 F=0x4000 T=127 (#1)
Apr 25 14:47:44 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
292 4.34.146.152:6346 L=238 S=0x00 I=32762 F=0x4000 T=127 (#1)
Apr 25 14:47:44 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
452 134.169.69.8:6346 L=219 S=0x00 I=33018 F=0x4000 T=127 (#1)
Apr 25 14:47:44 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
292 4.34.146.152:6346 L=40 S=0x00 I=33274 F=0x4000 T=127 (#1)
Apr 25 14:47:44 phys5 kernel: Packet log: forward MASQ eth0 PROTO=17 192.168.1.4:
1997 xxx.xx.xx.35:53 L=72 S=0x00 I=33530 F=0x0000 T=127 (#1)
Apr 25 14:47:44 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1
998 172.147.2.230:6346 L=48 S=0x00 I=33786 F=0x4000 T=127 SYN (#1)
Apr 25 14:47:44 phys5 kernel: Packet log: forward MASQ eth0 PROTO=6 192.168.1.4:1

ご参考までに, http://www.linux.or.jp/JF/JFdocs/IPCHAINS-HOWTO-4.html 
によれば, L はパケットのバイト長, S は TOS フィールド, I は識別子, F 
はフラグメントオフセット値, T は TTL(パケットの寿命) だそうです.

以上のログからは, 私は不具合の前後での違いを認識できないのですが, いか
がでしょうか.

> 　それから、Gnutella って使ったことがないので、ちょっと検索してみたらこ
> んな記事 http://www.zdnet.co.jp/news/0102/28/e_p2pworm.html も見つかりま
> した。
> 　ポートを監視されてみるのもいいかもしれません。

上記記事中に, 

「このワームのもう1つの特徴としては，通常のGnutellaのノードでのクエリ／
回答は，6000番代のポートを介して行われるが，感染しているマシンのユーザー
は，ポート99を介してやり取りされる異常なトラフィックに気付くはずだ。こ
のワームはすべてのリクエストに応えるため，トラフィックが増加すれば感染
したノードが機能停止になる可能性もある。」

とあったので, 上の実験で同時に 99 番ポートも tcpdump で監視してみまし
たが, 最初からネットワークが死ぬまでに 99 番ポートへのアクセスの形跡は
ありませんでした.

> 　また、差し支えのある IP アドレスを伏せて、ipchains で設定しているスク
> リプトを添えて質問されると、もっとわかるかもしれません。

ipchins の設定は以下のようにしております. eth0 がグローバル側, eth1 が
ローカル側です. 

# MASQ timeouts
ipchains -M -S 7200 10 160

echo 1 > /proc/sys/net/ipv4/ip_forward

ipchains -P forward DENY
ipchains -A forward -s 192.168.1.0/24 -d 0.0.0.0/0 -j MASQ
ipchains -A forward -s 192.168.2.0/24 -d 0.0.0.0/0 -j MASQ

# connection from foreign site to this host's port 80 via eth0 is denied
ipchains -l -A input -i eth0 -b -s 0/0 -d xxx.xxx.xxx.xxx 80 -p tcp -j DENY
ipchains -l -A output -i eth0 -b -s 0/0 -d xxx.xxx.xxx.xxx 80 -p tcp -j DENY

# connection from foreign site to this host's port 137-139 via eth0 is denied
ipchains -A input -i eth0 -b -p tcp --destination-port 137:139 -j DENY
ipchains -A input -i eth0 -b -p udp --destination-port 137:139 -j DENY
ipchains -A output -i eth0 -b -p tcp --destination-port 137:139 -j DENY
ipchains -A output -i eth0 -b -p udp --destination-port 137:139 -j DENY


BearShare と使うとネットワークが死ぬのはほぼ間違いないとようなのですが, 
その原因は今だによくわかりません.

----
和田