このページは福井県立大学の田中求之が2006年1月まで運用していた Mac のサーバ運用に関する会議室 「Web Scripter's Meeting」の記録です。情報が古くなっている可能性がありますのでご注意ください。

ADSL でサーバ その4

発言者:重松修
( Date Tuesday, July 10, 2001 11:50:37 )


コメントできなくなりましたので、新たにスレッドを起こしました。

現在、サーバの接続がとても重いので、その原因を調査しています。
とりあえず、ping で見る範囲では、

--- ganymede.ravi.ne.jp ping 統計 ---
送信パケット数 123, 受信パケット数 42, パケット損失 65%
Round-Trip 最小/平均/最大 = 266.7/394.2/637.7ミリ秒

のようにかなりの損失があります。

traceroute で調べたところ、

10  61.114.2.14 (61.114.2.14)  74.837 ms  75.666 ms  74.605 ms
11  61.114.1.98 (61.114.1.98)  74.896 ms  76.146 ms  74.865 ms
12  210.253.157.18 (210.253.157.18)  79.985 ms  90.213 ms  94.892 ms
13  210.188.137.210 (210.188.137.210)  95.072 ms  79.470 ms  89.342 ms
14  210.141.234.26 (210.141.234.26)  84.969 ms  97.411 ms  89.776 ms
15  210.249.132.238 (210.249.132.238)  310.613 ms *  193.940 ms
16  link-flets-ntt.edit.ne.jp (210.249.132.249)  139.881 ms  299.490 ms  239.566 ms
17  * * *
18  * * *

のようになり、全部調べられなかったのですが、10 番目のルータだと、

--- 61.114.2.14 ping 統計 ---
送信パケット数 10, 受信パケット数 10, パケット損失 0%
Round-Trip 最小/平均/最大 = 78.8/80.2/84.1ミリ秒


のように損失がなく、15 番目のルータだと、

--- 210.249.132.238 ping 統計 ---
送信パケット数 10, 受信パケット数 2, パケット損失 80%
Round-Trip 最小/平均/最大 = 335.7/448.1/560.6ミリ秒

という有様です。

これって、Flets, ADSL 以前の段階でかなりの損失が発生している
ように見受けられるのですが、ADSL や、私のサーバ設定に起因する
問題ではない、と考えてよいのでしょうか?

また、traceroute で * と表示され、検索ができないのですが、
これは何らかの障害、と考えた方がよいのでしょうか。


稲垣 さんからのコメント
( Tuesday, July 10, 2001 12:54:38 )

> また、traceroute で * と表示され、検索ができないのですが、
> これは何らかの障害、と考えた方がよいのでしょうか。

 なんとも言えませんが、必ずしも障害が起きているとは限りません。

 traceroute はICMPを使っていますが、最近悪戯をされる場合もある
のであえて応答しないような設定にしている場合や、遮るように設定して
いる場合もあります。pingはICMPをつかっていますが、その辺でアタッ
クやDosを受けたことがあるので、ルータの設定で遮る設定をしたこと
があります。


今泉克美 さんからのコメント
( Tuesday, July 10, 2001 13:35:21 )

>重松さんのパケット損失

PPPoEですよね?
ちょっとはずしているかも、、というつもりで
お聞き下さい。

PINGに使うパケットのデータ長を指定することって
できますか?
また、PINGのパケットの分割を禁止するオプションは
つけられますでしょうか?
(Winマシンからならできます)

重松さんのトラック積載量の喩えでいえば
大型トラック1台でいく、小型トラックの
ピストン輸送は許さない設定、すなわち
パケットの分割を禁止しておく設定で
どこまでのパケット長ならば
上記のトレースルートの経路で通過できるのか
実験すると、MTUの長さの調整の失敗なのか
どうかが判明すると思います。

パケット長さが500で、ためす、
パケット長さが1400で、ためす、、
など、色々な長さで調べるとよいと思われてなりません。
PINGは、自動的に繰り返し行ってくれるものを
使うと、損失がわかっていいかもしれません。
経路の手前のほうから順番に調べるしかありませんが。。。


以上は、経路MTU探索に対応していない機器が
経路上にあるかどうかの検査です。
(ブラックホールと言うらしいです)

ブラックホールがある場合には
パケットの分割禁止フラグをOFFにしても
MTUの大きいパケットを廃棄してしまう
古臭いルータ(経路上)があるとかで
(Microsoft調べ)
非常に剣呑です。

重松修 さんからのコメント
( Tuesday, July 10, 2001 13:44:00 )

稲垣さん、コメントありがとうございます。

traceroute の動作原理がよくわかっていないため、頓珍漢な質問だった
かもしれません。。。以前の障害発生時に、ループする、ということや、
今回のように調べられないのが何故か気になりますので、
一度勉強してみようと思います。

逆方向でも同じことを行ってみました。

Network Information: [ネットワーク情報]
a. [IPネットワークアドレス]     210.249.132.0-210.249.135.0
b. [ネットワーク名]             EDITNET-2
f. [組織名]                     EditNet株式会社

--- 210.249.132.238 ping 統計 ---
送信パケット数 100, 受信パケット数 99, パケット損失 1%
Round-Trip 最小/平均/最大/mdev = 56.685/68.765/153.967/15.501ミリ秒

Network Information: [ネットワーク情報]
a. [IPネットワークアドレス]     61.114.2.0
b. [ネットワーク名]             TTCN
f. [組織名]                     東京通信ネットワーク株式会社

--- 61.114.2.14 ping 統計 ---
送信パケット数 100, 受信パケット数 42, パケット損失 58%
Round-Trip 最小/平均/最大/mdev = 99.080/526.256/2497.745/493.030ミリ秒

という具合なんです。とりあえず、EditNet <-> TTCN の間が混雑している
ということなのかなと推測しています。

でも不思議なのは、EditNet のホームページへの接続は重くないんです。

私のところだと、ssh でシェル操作するのが耐えられないほど
重いし、途中で切れたりすることが頻発するのですが、
何をチェックすればよいのでしょうか?

/var/log/message を見ると、inetd が時々落ちているようなのですが、
(exit status 1) これは何かしらのアタックを受けている? のでしょうか。

現在のところ、ルータでフィルタは特に設定せず、特定のポートを
Linux 機にフォワードしています。





今泉克美 さんからのコメント
( Tuesday, July 10, 2001 13:54:27 )

ちょっと舌たらずのようですのでコメントを追加します。

経路MTU探索を利用されている場合には
パケットの分割を禁止するフラグが
パケットに常時、立ちます。

すると送ったMTUの長さを受けつけないルータ
(ホスト含む)は、エラーを返します。
エラーパケットには、
「この長さならOKだよ、送りなおしてね」というMTU値が
設定されます。
送り手側は、このエラーパケットのMTUの値に従って
再度送信を試みます。
以上は、経路MTU探索を使う場合には、自動的になされます。

(重松さんのはこれに該当するかもしれませんね。)

経路の途中に経路MTU探索に対応していない機器があると
エラー応答パケットに、その機器のMTU値を含めない場合が
あります。
これでは、通過できるMTUがわかりませんので
送り手側は、単純に再送してしまいます。
何回かリトライするうちに通信断になるはずです。

以上を補完するために
経路MTUブラックホールDetectという機能が
あります。
再送回数が2回に達すると、自動的に分割禁止フラグをオフにして
分割を許し、パケットが該当ルータを通過できるように
します。ブラックホールなら、体を縮めて通るような感じでしょうか。

ところが、マイクロソフトの調べでは、これでもダメな場合があるとか。
MTUが大きいパケットを、廃棄するルータがあって、体を縮める
ゆとりすら与えないと考えて良いでしょう。
送り手側で、MTUを自動的に576程度に下げれば
これらの変なルータを通過できると考えられています。

(こうなるとブロードバンドの利便性が失われますよね)

以上、日経バイトからのパクリでした。

重松修 さんからのコメント
( Tuesday, July 10, 2001 14:05:35 )

今泉さん、こんにちは。

今回の問題は、おそらくブラックホールとは関係ないのではと思います。
そう思う理由は、パケットサイズを大きくすると、
100% のロスになりますが、今回は、ロスにばらつきがあるので、
それ以外の理由であると思っています。

原因を調査しようにもリモートホストに接続できないほどに重いので、
継続してできることを調べているのですが、14 段のルータは、
EditNet のもので、以降、15, 16 まで EditNet のようです。
それ以降は、どうなっているのかわかりませんが。
# どうもこの先は、flets 網のようです。


今泉克美 さんからのコメント
( Tuesday, July 10, 2001 15:56:14 )

重松さんのおっしゃる通りのようですね。
なお、こちらから失礼ながら
Tracertしましたが
16の
link-flets-ntt.edit.ne.jp 
の次は
ガニメデ・ラヴィ
でした。
かっこいい名前ですね。>重松さん


重松修 さんからのコメント
( Tuesday, July 10, 2001 17:45:02 )

今泉さん、こんにちは。
わざわざ調査いただきまして、ありがとうございます。
フレッツ網はそうすると、見えないんですね。
勉強になりました。

そうそう、マシンの名前ですが、ガリレオ衛星の名前を使ってたんですが、
さすがに最近はネタが切れてきました。覚えやすくていいんですが、
逆にいえば、類推されやすい (io や europa もあるだろう、って)
というデメリットもあるようですね。

ちなみに、外から見た ganymede は内から見た ganymede とは別の
ルータ君です。


今泉克美 さんからのコメント
( Wednesday, August 01, 2001 19:46:32 )

ADSLの工夫。
なんか、みなさん工夫したいらっしゃるようで。


鉛が一番!
http://salami.2ch.net/test/read.cgi?bbs=isp&key=990663554&ls=50


稲垣 さんからのコメント
( Thursday, August 09, 2001 15:16:30 )

 別スレッドで話題になっていますが、CodeRed関連です。

 NTT-ME の BA512をグローバルアドレスでの運用をしていると、通信ができなくなります。
対策は現状のところないようで、後継機のBA512Rだと大丈夫とのことですので、早速購入し
てきました。

 InfoSphere形式?だともろダメみたいですね。普通にNATを使ったものなら大丈夫だと思い
ますが・・・。

 よくも悪くもいろいろなネットワーク機材がブラウザで設定できるようになったけど、こう
いう弊害も起きてしまいますね。

重松修 さんからのコメント
( Thursday, August 09, 2001 16:43:27 )

稲垣さん、こんにちは。

NTT-MEのルータですが、外部から WEB 設定できなくすることは
できないでしょうか?

セキュリティ、という観点からも、ブロードバンドルータは外部からは
telnet, http などで接続できないものが望ましいですね。

ここでいうセキュリティとは、狭義の、Code Red に耐性のある、
という意味ではなくて、たとえば、http でログイン画面が表示される
だけで、ルータの機種がわかりますから、たとえば、固有のセキュリティの
未知の問題があったときにクラックされる危険性を軽減できるのではと
思っています。

稲垣 さんからのコメント
( Thursday, August 09, 2001 17:05:04 )

 BA512では出来ないようです。ただ、NATを使った場合には大丈夫な感覚
がしますが、ちょっとマニュアルを見ないと分かりません。

 BA512RだとWAN側のフィルタがつけれますので、それで対応できません
かね。自分はLAN側になるはずですので、WANから自分向けの80portを止め
る設定にすれば大丈夫でしょう。
#というか、Rがついてやっと最低レベルに追いついた感じがします。

いその@とし研 さんからのコメント
( Thursday, August 09, 2001 18:00:40 )

>  BA512では出来ないようです。ただ、NATを使った場合には大丈夫な感覚
> がしますが、ちょっとマニュアルを見ないと分かりません。

思いつきです。
ルータにグローバル・アドレスが1つ割り振られるという状況の場合、Web サー
バをたてようとすると port 80 をローカルなマシンにマッピングしますよね。
この段階で、結果的に、外部からはルータの設定用 Web に入れなくなりますよね。
これを使えば、WAN 側のフィルタがなくてもブロックできないでしょうか?
# 例えば、マシンが存在しないローカル・アドレスにマッピングするなど...

NTT-ME のルータのことはよく知らないので、外していたら叱ってください。

重松修 さんからのコメント
( Saturday, August 11, 2001 22:27:51 )

新しいファームウェアがリリースされた模様です。

http://www.ntt-me.co.jp/bar/down-ba512.html

これで改善されるのでしょうか、謎ですが。
もしだめなら、CodeRed 対策が完了するまで
販売を自粛して欲しいものですね。>NTT-ME

稲垣 さんからのコメント
( Sunday, August 12, 2001 10:36:01 )

 とりあえず、リリースノートを見ると、それなりに改善はされている
様です。

### 以下引用

   [2] 設定用WWWサーバ機能関連
       WAN側ポートに対してTCP80番宛のパケットが多量に到着した場合、本製品が
       ハングアップする場合がある不具合を修正しました。
       @ WAN側ポートに対する、icmp、http、telnetのリクエストをすべて無視。
       A ローカルサーバの工場出荷時設定を消去。
       注意:この変更に伴い、インターネット経由の設定画面アクセスは不可能に
       なります。

###

 とあるので、少なくともCodeRedへの対策は出来ているようです。また、
ちょっと原理はつかみかねますが、インターネット側から管理画面にアクセス
出来なくなるようですね。


→  BA 512 ファームウェアリリースノート

稲垣 さんからのコメント
( Sunday, August 12, 2001 10:39:43 )

 自己フォローですが・・・

>ちょっと原理はつかみかねますが、インターネット側から管理画面にアクセス
>出来なくなるようですね。a

 自分の発言を読み直したのですが、単純にWANポート(のIP)へのhttpアクセス
を無視するだけのようですね。
 ただ、これだとグローバルアドレス1つでのWebサーバ運用は出来なくなる
んじゃ無いかなと思いますが、どうなんでしょうか?

yu@muon さんからのコメント
( Sunday, August 12, 2001 11:41:57 )

port mapping をしない場合は http アクセスを無視、port mapping を設定
した場合は当該ホストに forward するようになってるんじゃないでしょうか?

そのルータを知らないので単なる想像ですけど、ルータはふつうそういう動
作をするように設定する場合が多いでしょうから。

田中求之 さんからのコメント
( Friday, August 17, 2001 17:22:24 )

MacHTTP も Code Red のアタックでバッファー・オーバーランを起こしてしまう
可能性があるそうで、近いうちに、この問題に対処した新しいベータ版を
出すそうです(ML で Chuck さんが言ってた)。

田中求之 さんからのコメント
( Friday, August 17, 2001 17:23:58 )

あ、もう新しい 2.5b1 というのが出てました (^_^;;

→  MacHTTP Org

田中求之 さんからのコメント
( Friday, August 17, 2001 19:44:09 )

うげぇ、全然関係ない話題に書き込んでしました。すみません。

重松修 さんからのコメント
( Thursday, September 27, 2001 09:48:11 )

BAR-SW4P ですが、新しいファームウェアがでてました。
で、更新してみました。以前より、それなりに通信できているような、
そうでもないような。。。

それはそうと、少し気になることに気づいたのでおたずねしますが、
私の環境では、一旦回線を切ると、モデムの電源を落とさないと、
しばらく通信ができません。

以前、アナログモデムの時代には、輻輳をさけるために、
話中などの時にしばらく再度電話できないような規制があったと
思いますが、ADSL にもそういう制約はあるんでしょうか?

いかんせん、BAR-SW4P の場合、失敗した理由 (エラー番号) などが
全く表示されないので、原因の特定のしようがないのですが、
みなさんのところはどうでしょうか?

もし、そうだとすると、サーバを運営する回線としては、
ちょっと厳しいものがあるな、と思うのです。