[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:44999] Re: 特定のネットワークからの接続が不安定
柴田(あ)です。
Debian Users ML にはだいぶん以前にポストしていたの
ですが、停まっていたのに気づかず間抜けでした。
吉藤さんの PMTU blackhole は
http://www.google.co.jp/search?hl=ja&c2coff=1&rls=GGLG%2CGGLG%3A2005-34%2CGGLG%3Aja&q=PMTU+blackhole&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
をみると今回の結果とあわせて、当方が非常に疑わしく
思えてきました。
icmp フィルタをいじるのはこのメイルを打ってから。
<20051026.004141.74737581.yoh@xxxxxxxx> の、
"[debian-users:44965] Re: 特定のネットワークからの接続が不安定" において、
"Wed, 26 Oct 2005 00:41:44 +0900" 発信のメイルで
"MATSUDA Yoh-ichi / 松田陽一 <yoh@xxxxxxxx>"さんは書きました：
> > ある特定のネットワークからの接続が不安定ですので、
> > もし同じ状況に陥ったことがあるとか、この辺を
> > チェックしてみたらということをご指摘いただけませんでしょうか？
> >
> > ■状況
> > R1,R2 はルータで左側は 172.16.0.0/16
> > それぞれのルータの右側はサブネット
> >
> > 接続構成
> > +-R1−−− Linux server 172.18.250.50 Sarge
> > |
> > +-R2−−− Linux server 172.30.17.2 Woody
> > |
> > Linux server 172.16.10.15 Woody (potate あがり)
> potato
>
> このネットワーク構成図の IP アドレスは、これで正確ですか?
> 実際はどれがグローバル IP ですか?
これらの IP アドレスは正確です。
potato のスペルミスはおっしゃる通りです m(_|_)m
グローバル IP アドレスはこの中には存在
いたしません。
実際のイントラネットの中での組み合わせです。
> > 付帯事項
> > ・ R1 - 172.18.250.50 間は ping はつかえません (ブラスタ対策)
>
> 問題解決を優先するなら、この「ブラスタ対策」は外すべきです。
> 理由は、 traceroute が使えなくなるからです。
はい、これからはずしてみます。
いまだに apache のログに XXXXXX などのように
Code Red でしたっけ？なものを見るにつけ、
シーラカンスのように絶滅していないんだなぁと
思うと少々怖いものがありますが、少なくとも
問題解決するまでははずしたいと思います。
ちょっと手間がかかるので、他のことをやりながら
ブラスタ対策をはずす設定を出したいと思います。
> > ■問題点
> > R2 の右のサーバから 172.18.250.50 の web サーバから
> > データをもらえません。
> > 要するに web ペイジが表示されないです。
> >
> >
> >
> > ■ためしたこと
> >
> > ・ 172.30.17.2 から ping R1 の左側→ OK
>
> 172.30.17.2 から ping R1 の右側はどうですか?
そちらも問題ありません。
on 172.30.17.2 で
ping R1 → ○
ping R2 左側 → ○
ping 172.16.10.15 → ○
on 172.16.10.15 で
ping R1 → ○
ping R2 左側 → ○
ping 172.30.17.2 → ○
> > ・ 172.30.17.2 から wget http://172.18.250.50/ をすると
> > 下のような表示で止まります。
> > しょうがないので Ctrl+C してファイルをみるとダメです。
> > ・しかし web としては反応しているように見えます。
> > 172.30.17.2 から telnet IP 80 しました。
> > ・ 172.30.17.2 から wget http://172.16.10.15/ をすると
> > 普通に取得できます。
>
> 試しに、 index.html のサイズを 10 byte 程度の極小のファイルに
> して wget してみるとどうなりますか?
これは思いつきませんでしたので、試してみました。
結果は「小さなファイルは wget できず、ある大きさ
よりも大きくなると wget の途中で止まります。」
その差ですが、下記のように 1403 Bytes →×
1402 Bytes →○
+---------------------------------
| ~/tmp$ wget http://172.18.250.50/~shibata/
| --07:32:59-- http://172.18.250.50/%7Eshibata/
| => `index.html.19'
| Resolving 172.18.250.50... done.
| Connecting to 172.18.250.50[172.18.250.50]:80... connected.
| HTTP request sent, awaiting response... 200 OK
| Length: 1,403 [text/html]
|
| 0% [ ] 0 --.--K/s ETA --:--^
| ~/tmp$ wget http://172.18.250.50/~shibata/
| --07:33:17-- http://172.18.250.50/%7Eshibata/
| => `index.html.20'
| Resolving 172.18.250.50... done.
| Connecting to 172.18.250.50[172.18.250.50]:80... connected.
| HTTP request sent, awaiting response... 200 OK
| Length: 1,402 [text/html]
|
| 100%[================>] 1,402 171.14K/s ETA 00:00
|
| 07:33:17 (171.14 KB/s) - `index.html.20' saved [1402/1402]
+---------------------------------
> 172.16.10.15 から wget http://172.18.250.50/ をするとどうなり
> ますか?
これは全然問題ありません。
+---------------------------------
| $ wget http://172.18.250.50/
| --09:42:00-- http://172.18.250.50/
| => `index.html'
| Connecting to 172.18.250.50:80... connected.
| HTTP request sent, awaiting response... 200 OK
| Length: 31,575 [text/html]
|
| 100%[==============>] 31,575 230.11K/s ETA 00:00
|
| 09:42:00 (230.11 KB/s) - `index.html' saved [31575/31575]
+---------------------------------
>
> > ・ 172.30.17.2 から 172.18.250.50 へ ssh でログインできます。
> > ・ ナゾな現象： ps a も ps x もできますが ps ax で固まったようにみえます。
>
> 巨大なテキストファイルを cat してみるとどうなりますか?
これまた興味深いことがわかりました。
+---------------------------------
| ~/public_html$ ls -la index.html
| -rw-r--r-- 1 shibata shibata 1322 2005-10-29 10:05 index.html
+---------------------------------
このファイルは cat できますが一バイトでも大きいと
固まったように見えます。
> > ・ ナゾな現象： free はできますが top で固まったようにみえます。
ふと、 1322 バイトフキンになにかあるのかと思い
head -c で調べてみました。
+---------------------------------
| ~/public_html$ ls -la
| total 516
| drwxr-xr-x 3 shibata shibata 4096 2005-10-29 09:50 .
| drwxr-xr-x 6 shibata shibata 4096 2005-09-18 12:36 ..
| -rw-r--r-- 1 shibata shibata 471072 2005-10-29 09:50 bigfile.txt
| -rw-r--r-- 1 shibata shibata 1322 2005-10-29 10:05 index.html
| -rw-r--r-- 1 shibata shibata 29442 2005-10-29 09:49 largefile.txt
| drwxr-xr-x 6 shibata shibata 4096 2005-09-24 18:02 tmp
| ~/public_html$ head -c 1323 bigfile.txt ←これは可能
| ~/public_html$ head -c 1324 bigfile.txt ←これは固まるように見える
+---------------------------------
> > ・ ナゾな現象：172.30.17.2 から 172.18.250.50 ログインして
> > 実行すると固まるコマンドがあるのに、 172.16.10.15 から
> > 172.18.250.50 へログインして固まることはありません。
> > だからこうやって現象を報告できるのですが・・・
つまりいっぺんに送るデータの大きさに問題があるのだろうと
いうことがわかってきました。
> > ・一応パケットフィルタリングが怪しいと思いフィルタは
> > 単純化してあります。 172.18.250.50 で実行
> > +-----------------------------
> > | $ sudo /sbin/iptables -n -L
> > | Chain INPUT (policy ACCEPT)
> > | target prot opt source destination
> > | ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
> > |
> > | Chain FORWARD (policy ACCEPT)
> > | target prot opt source destination
> > | ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
> > |
> > | Chain OUTPUT (policy ACCEPT)
> > | target prot opt source destination
> > | ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
> > +-----------------------------
>
> 全部 ACCEPT にしちゃってるなら、
>
> > コレを実現するためにしたのスクリプトを動かしています
> > +-----------------------------
> > | IPTABLES=/sbin/iptables
> > | $IPTABLES -F INPUT
> > | $IPTABLES -F FORWARD
> > | $IPTABLES -F OUTPUT
>
> これだけで十分じゃないですか?
>
> > | $IPTABLES -P INPUT ACCEPT
> > | $IPTABLES -P FORWARD ACCEPT
> > | $IPTABLES -P OUTPUT ACCEPT
> > | $IPTABLES -t nat -A POSTROUTING -o $IFOUTER -j MASQUERADE
> > | $IPTABLES -A INPUT -i lo -j ACCEPT
> > | $IPTABLES -A FORWARD -j ACCEPT
> > | $IPTABLES -A OUTPUT -j ACCEPT
> > +-----------------------------
>
> これは不要かと。
実はポリシを DROP にしていたのですが、
この問題にハマって一時的に全部 accept に
しています。
172.30.0.0/16 の下には他にもあるのですが、
リモートでコントロールできるのは
これくらいなので、コレで確認しています。
> > ・詳しく調べていませんが、 172.18.0.0/16 の下からは
> > web on 172.18.250.50 は普通に参照できます。
> >
> >
> > ■まとめ
> > ・ 172.16.10.15 から 172.18.250.50 に ssh ログインして
> > 何でもでき、何も問題がない（当然）
> > ・ 172.30.17.2 のサーバから 172.18.250.50 の web サーバを
> > 参照しても希望するデータは出てこない
> > ・ 172.30.17.2 から 172.18.250.50 に ssh ログインして
> > できることとできないことがある。
> > 反応がなくなったのをできないと判断した（プロセス ID もない）
>
> > どこでナニが起こっているのでしょうか？
> > 私はナニを見落としているのでしょう？
> > ご指摘いただけますと大変ありがたいです。
>
> - 172.18.250.50 から 172.30.17.2 は参照出来るのですか?
> 出来なくても良い設定にしているのですか?
できなくてもいいのですが、参照できますというか
ssh ログインできます。
で、わかっタコとを書きます。
・ 172.30.17.2 、 172.18.250.50 、 172.16.10.15 の
それぞれは互いにどの組み合わせでも ssh login は
可能である
・ただし、172.30.17.2 から 172.18.250.50 にログインした
時のみ不具合が起こり転送先頭から何バイト目か付近に
何かキーがあるように思える
根拠１） wget の場合、 1402→○、1403→×
根拠２） cat の場合、 1322→○、 1323→×
根拠３） head の場合、 1323→○、 1324→×
・ですからダメだった ps afx も
$ ps afx | head -c 1323
とすれば可能に（笑）→全然解決してません。
> - 各マシン上の route の実行結果は?
> - 各マシン上の default route は?
あわせて書いておきます。
172.16.10.15 だけドタバタした数字になっていますが、
ヘンに削るよりはと思い全部出しておきます。
172.30.17.2 のマシンでは
$ /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.30.17.0 * 255.255.255.0 U 0 0 0 eth0
192.168.17.0 * 255.255.255.0 U 0 0 0 eth1
default 172.30.17.1 0.0.0.0 UG 0 0 0 eth0
172.18.250.50 のマシンでは
$ /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.5.0 * 255.255.255.0 U 0 0 0 eth0
172.18.0.0 * 255.255.0.0 U 0 0 0 eth1
default 172.18.0.1 0.0.0.0 UG 0 0 0 eth1
172.16.10.15 のマシンでは
$ /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.21.0 * 255.255.255.0 U 0 0 0 eth2
172.30.23.0 172.16.252.128 255.255.255.0 UG 0 0 0 eth0
172.30.38.0 172.16.252.128 255.255.255.0 UG 0 0 0 eth0
192.168.3.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth1
172.30.17.0 172.16.252.128 255.255.255.0 UG 0 0 0 eth0
172.30.32.0 172.16.252.128 255.255.255.0 UG 0 0 0 eth0
172.30.16.0 172.16.252.144 255.255.255.0 UG 0 0 0 eth0
172.30.33.0 172.16.252.161 255.255.255.0 UG 0 0 0 eth0
192.168.1.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth1
172.30.19.0 172.16.252.128 255.255.255.0 UG 0 0 0 eth0
172.30.34.0 172.16.252.128 255.255.255.0 UG 0 0 0 eth0
172.30.13.0 172.16.252.128 255.255.255.0 UG 0 0 0 eth0
172.30.12.0 172.16.252.128 255.255.255.0 UG 0 0 0 eth0
192.168.10.0 * 255.255.255.0 U 0 0 0 eth1
172.30.24.0 172.16.252.128 255.255.255.0 UG 0 0 0 eth0
172.18.0.0 172.16.240.1 255.255.0.0 UG 0 0 0 eth0
172.16.0.0 * 255.255.0.0 U 0 0 0 eth0
172.20.0.0 172.16.240.2 255.255.0.0 UG 0 0 0 eth0
default 172.16.0.2 0.0.0.0 UG 0 0 0 eth0
> - 各マシン上の traceroute の実行結果は?
これはブラスタ対策をはずしてからとします。
一応 telnet hoge 80 などはそこそこに到達するので
そういう問題とは違うようにも感じているので、
ブラスタ対策の設定を引っ張りだしてから
やってみます。
> 取り敢えず、ブラスタ対策なる設定は外した上で、 ping や traceroute
> を実行して貰わないことには話が始まらないと思います。
はい、了解です。
> 「どーしても設定しなきゃならない」というなら、 IP アドレス範囲を
> 特定して ping を deny すれば良いです。
>
> S1(172.18.250.50)
> > +-R1−−− Linux server 172.18.250.50 Sarge
> > | S2(172.30.17.2)
> > +-R2−−− Linux server 172.30.17.2 Woody
> > | S3(172.16.10.15)
> > Linux server 172.16.10.15 Woody (potate あがり)
>
> S1, S2, S3, R1, R2 の route の実行結果を見る。
> 特に、 S2 のルーティングテーブルに 172.18.0.0/16 があるか否かを注目。
S2 のルーティングテーブルには R2 へのルーティングが
確保できていればいいかと思いましたが、そうでも
ないんでしょうか？
R2 では 172.18.0.0/16 は R1 を next hop として
設定しているつもりで、実際に ssh でコネクションが
張れること、小さいファイルなら wget できることから
ルーティングはあまり疑ってないのですが、この辺が
マズいのかもしれませんね。
洗い直してみます。
> 私が思い付くのはこんなところです。
ありがとうございます。
少なくともダメ条件と、OK 条件がより鮮明になりました。
> ところで、ルータ R1, R2 は一つに出来ないんですか?
> 多分、その方がシンプルになると思うんですけど。
残念ながらルータである必要があります。
つまり、ルータの左側は Ethernet ですが、右側は
Ethernet ではないのです。
R1 の右側は同軸ケーブルであり、
R2 の右側は光のケーブルなので、
一個にはまとめられません。
全部 Ethernet であれば L3 スイッチなどに
できるんですが、違う L2 を持つものをつなぐのが
そもそもなルータだと思っていますから、いわゆる
ルータらしい使い方かなぁと思っています。
ナニはともあれブラスタ対策をはずす方向で
考えます。
ご協力ありがとうございます。
--
SHIBATA Akira ケーブルテレビはまちづくり
shibata@xxxxxxxxxxxxxx phone : +81-429-74-3611