1.5M対応のものから、8M対応のモデムに換えて、ますます速度低下してるわけですが。
（でも、ずっと560kbpsだから、もしかすると前より「安定」してるとか？）

電話線の、家の中の配線が良く無いんじゃないかと思ってます。
モジュラージャックまで、ひょろひょろした細い線が、10m近く引っ張ってあるもので。
しかもそれが、LANケーブルに並行して通ってたり、冷蔵庫の横を通ってたりするし…

せめてそのあたり改善できないかと、少し調べてみたんですが。
この手の工事…モジュラージャックの移設になると、工事担任者という資格が必要なのだそうで。
（元々は電電公社等の社内資格だったものが、電気通信事業法で国家試験になったものらしい）

どうしようかな、これは業者に頼むしか無いのか…
でもこんな作業でン万円も取られてたら、ぼったくり臭い…
と悩んでると、親父さんが、
「俺は資格無いのに工場の中で電話を数十本引いたぞ。自分でやっちまえばいい」
とか言うんですよ。

それはちと事例が違うのでは。

担任者って、工事を監督するだけでもいいんです。
資格の無いものが作業するさまを、後ろで見てるだけでもOKなんですよ。
当時、親父さんに作業の指示を出したり、様子を見に来た人が、
資格を持ってた方かどうかなど、今では知る由もありませんが。

そもそも、工場内の電話は、おそらく内線電話でしょう。
それは専用線扱いなので、件の資格は必要ないんです。

よって親父さんの体験談は、この場合参考にならないと思われ (;´Д｀)

（何か間違いがあったら指摘してくださいです m(_ _)m ）


そういったことを調べてたら、
今まで知らなかったことも、いくつか知ることができました。

電話のコネクタの名前は、RJ-11と呼ぶらしいとか。
（LANのコネクタはRJ-45という）

電話は、6芯のうち2芯しか繋がってないとか。
（ホームテレホンとやらは4芯繋がってたりするらしい）

2芯には、ちゃんと極性があるとか。
（最近の電話は極性違ってても使えるような仕組みらしい。
ただ、モデムの類を接続する場合は影響があるのだとか。
電話線には、電話を駆動する為の電流が流れてるので、
間違えて接続した場合、下手すると壊れる場合もあるのだそうで…機器によるんでしょうけど。
ISDNは極性を間違えると繋がりませんが、
極性反転SWがついてる機器がほとんどなので、それで切換えれば問題無し。
なんかこのへん、U氏がハマってなかっただろうか…？）

回線チェッカーなるものが存在するとか。
（モバイルする人は、持ってて当たり前のアイテムだそうで。
モバイルしたことないから存在すら知りませんでしたよ。
海外の空港・ホテルなどで、回線が使えるかどうか…
過電流が流れてないか（デジタルかアナログか）、
極性反転してないか、予想通りの結線がされてるかを調べられるのだとか。
極性反転や結線が違ってたら、
回線チェッカーのSWで極性反転したり、
あるいは変換コネクタを使って対処するのだそうです。）

知ってる人にとっては「そんなの常識だろ」という事ばかりでしょうけど、
自分にとっては知らないことばかりで、勉強になりました。


ていうか。

もしかすると、そもそも電話の仕組みって…
高校の授業でやってたかもしれん…(爆)
自分、何も覚えてないです…トホ

教科書、残ってたかなぁ…
捨てちゃった気がするなぁ…

親父さんと一緒に、親父さんの友人宅へ。
ネット関係の相談を受けてきました。

なんでも、OCN関係の業者さん（なのか？）から、
　「福島県郡山市では、ADSLは提供されてない」
と言われ、OCNの従量制プランを契約してしまったらしく。

(;´Д｀)

郡山市は、フレッツADSLどころか、Yahoo！BBも来てますよー
（仮に、その地域が光収容云々でサービス利用できない故の発言だとしても、
その旨顧客にしっかり説明しておくべき）

どうも最初に、
　「月3000円ぐらいのADSLプランがあるそうですね」
と相手に尋ねたらしくて。
　「（…このままじゃ客にならん。なんとかせねば）」
と思われて、嘘をつかれたのかしら。
OCNだと、フレッツADSLのプランで、合計で月5000円ぐらいになりますから。
（つか、ウチが現在そのプランなんですが。）

しかし、どうして客を騙すかな。
一度騙された客は根に持ちますよ。
OCNの売りは「信頼」だと思ってたんだけど。
料金高い上に、客の信頼すら失ったら、もう商売にならないのでは。

誠意ある対応は、客の為だけにするわけじゃなくて。
将来の自分の利益に繋がるからするわけで。
目先の利益に囚われて、自分の首締めてちゃアカン…


それにしても、郡山市はいいなぁ。
須賀川市は、倍の料金払わないと、ADSL使えないよ…
まあ、使えるだけマシだけど…

下りが500kbpsしか出てない…
回線状況が悪化してるのか…？
上りは速度変わってないんだけど。
下りの周波数帯で何か起きてるのかな。
回線切断の原因もそのへんなのか？

久々にIRCチャットしてたら回線が突然切れて困った。
そういや夕方頃も、親父さんから「ネットが使えない」と言われたっけ。
ルータ自体の動作が異様に遅くなってた。なんでやろ。
昨日の夜も切れてた。ルータは生きてたけど、WANが見えなかった。
どうもここ数日、回線自体が切れる。
LAN全体が遅くなってるとか、そういうのじゃないのが困る。

モデムに原因があるのか、ルータに原因があるのか。
あるいは回線の向こうに原因があるのか…
OCNやフレッツADSLのサイトでは、故障や工事情報は見当たらないし。
とすると、ウチの中の問題なのか…

自鯖へのアクセス急増の理由がわかりましたですよ。（たぶん…）

2chにリンクが貼られてた模様(爆)
…そりゃ増える罠。

ひとまず仮対策ではありますが、Webサーバの設定を変更し、ディレクトリのファイルリスト表示をOFFにしておきました。
これでディレクトリの中身が丸見え、ということはないはずです。

状況把握、及び、上記のような状態にするまでに時間がかかってしまい、Y氏にはご迷惑をおかけしました。申し訳ないです。（先のような状態にする以前に、氏自身のほうで、気遣いをしてくれて、それら人気のあるファイルを消してくれていたのです。）
結構な時間をかけてアプしていただいたのに…本当にY氏には申し訳無いことをしました。
自分がリンクを貼ったわけではないとはいえ、 そもそも根本的な原因は、誰でもディレクトリ内を閲覧できる状態でサーバ運用していたという杜撰さ、甘い考え、サーバ管理者としての自覚の無さにあったわけで…
ホント申し訳無い。ゴメンナサイです… m(_ _;)m

ていうか、実はまだ私も落としてないファイルがいくつかあったりして（自爆）、故に今現在私自身も大変厳しく痛みが身に染みておりますので許して… (T_T)

---

とりあえず今回の件で、誰もが自由に各ディレクトリの中身を知る事ができる状況はよくない、と痛感しました。
いや、以前からヤバイと思ってはいたんですけど、 「こんなところには誰もこないだろうし。アクセス数だって、現に全然無いしなぁ」と、 つい利便性を優先してしまっていたのです。反省しております。

今のところ、将来的に、パスワードを各フォルダに設定できるようにしようか、などと考えてます。 少し調べてみたところ、設定次第で、アカウントを持ってる方がパスワード認証させるフォルダを自由に決める事ができるようです。 ただ、肝心のパスワードをどうやって設定するか、まだわかってません。パスワードを暗号化する必要があるので、その方法をこれから調べてみます。

---

今回、Webサーバのアクセスログの中の、Referrer（どのページから飛んできたか）を眺めてて、上記のような事態になってることを知ったわけですが。
自分、ログをちゃんと調べるまでは、数人の方がアクセスしてる程度なのだろう、と勝手に思いこんでいたんですね。 それにしては、どうしてこんなに負荷がかかるのだろうと、不思議に思っていたのです。

ところがどっこい。どうも、数十人の方が、同時にアクセスしていたようで(核爆)
Apacheには、 「Apacheの子プロセス状況をリアルタイムに閲覧する機能」 があるのですが、それを見てビックリ。 普段は２、３個しか見かけない、応答プロセスを示すマークが、画面を覆い尽くすほど大量に…ヒイ
さらに、アクセスしてきた方の人数を調べて仰天。顔面蒼白 ＜言いすぎ


それにしても、元々のカキコ自体はなんてことないモノだし、レスもついてないし、 パッと見は誰も注目してないカキコのように見えたのですが。 ↑考えてみたら、そこだけとは限らないんですよね…うーん…
いやはや、2chはスゴイ、というか恐ろしい…
いやいや、Webそのものからして、いつでもそういう危険性と隣り合わせだったのですね＜って今頃そんなのんきなこと言ってるなよゴルァ
普通に利用しようとして、あの数なんだから… これが悪意をもって集中的にアクセスした日には、某業界団体のサーバがアッサリ落ちてしまったのも、なるほどガッテン、ですねぇ ＜って余りモノで作ったサーバと比べるなんて失礼すぎるぞゴルァ


それにしても、これだけアクセスが増えるなら、商売をやってる方は、2chを利用しない手はないですねぇ…
「○○、全然期待してなかったけど、実は結構スゴかったぞ」などとユーザのフリして書けば、売れなかった商品も、みるみるうちに…
…そう上手くはいかないよね (;´Д｀)
でも、結構そういう使い方してる業者の人、多いんだろうなぁ…


そういや自分、以前どこかで、 「光引いて鯖立てれば、もしかすると何か商売できるかも？」と、 ほざいてしまった記憶があるんですが。
無理。絶対無理。甘い。甘すぎる。甘々。寝言。
色んなモノ…関連知識とかアイデアとかも必要になるでしょうが、 なによりもまず、ああいったアクセス数にも充分耐えられる、屈強なハード構成… つまり、「やっぱり金が必要」なのだと思い知らされました。


それにしても…皆さん、DLできてたんだろうか…
200kbpsを数十人で共有…
DL…できてたのかな？ ソレって… (;´Д｀)？
微妙に申し訳無い気分…自宅サーバなもんでスイマセン。
回線遅いし、LAN構築は適当だし、サーバは余りモノで出来てるもんで…

---

おそらくですが、ここ数日のLANの速度低下も、サーバへのアクセス過多のせいだったのだろうと思います。
何せ、10BASE-Tで構成されたLANの中を、ひっきりなしに何十ものアクセスが行き来してるわけですから、 一人当たりの転送速度は遅くても、「やり取りする」為の情報だけで、負荷はかなりのものだったのでしょうね。
しかもそのやり取りは、関係ない、LAN内の全てのPCにも送られてくるわけで…（リピータHUBを使ってますから…）

実は、自分の使ってるメインPCにも、影響らしきものが出た…ような気も。
ディスプレイカードの動作が今まで見たことないような異常状態になりまして。 （いやはや、画面がグチャグチャになって焦りました。 CPU・OS自体はまともに動いてたんで、あてずっぽうの操作でなんとか再起動させましたが。）
おそらく、メインPCのNICが高負荷に耐えられなくなり、その影響が他のカードにまで及んだのでは、 と想像してるんですが、どうなんでしょうか。そういうことってあるんですかね？ 只の妄想なのかな。妄想なんだろうな。

---

いやはや、今回は勉強になりました。
ネットワークの高負荷状態なんて、自分のような個人レベルでは、普段滅多に味わえないことなのでしょうし。とても貴重な体験ができましたです。
こういう機会がなければ、NICに性能差があるとか、カニさん云々とか、LANについての知識等々も、ずっと知らないままだったかも。
でも、こういった場合でも、LAN構成を練り直せば、全体的にはそこそこ使えるようになるんでしょうか？
そのあたりの課題は残ってしまいました。まだまだ自分、修行が必要であります。

それにしても、世間のネットワーク管理者の方々はスゴイな… 日々こういう状況を体験してるのか…改めて感服であります。
皆様も是非、社内外のネットワーク管理者の方に、たまには常日頃、感謝の意を示してあげてください…

いやはや…長々と実験に付き合って頂いた皆様方、大変お手数かけました。
お蔭様で、FTP利用時のタイムアウトの件、原因が特定できました。

どうやら、ルータ（Corega BAR SW-4P）が原因らしいです (TーT)


らしいと言うのは…
某2chで質問して、一言二言のレスで確証を得た、ということでありまして…
何せ2chですから、レスの信憑性は怪しい…
煽り・騙りの可能性も充分あり得るわけですが…

が、しかし…
今までの実験結果からすると、自分にはそうとしか思えない…
ていうか、絶対コレだろ、みたいな。

---

不具合が起きる流れとしては、おそらく以下のような感じです。


FTPでファイルを転送した直後、
FTPサーバの「ファイル受信が成功したよ」という返事は、
21番ポート（制御ポート）を介して、
FTPサーバ（ProFTPD）から、FTPクライアント（FFFTP）に送られます。

その為、
「データポートを利用したファイル転送が終了するまでの間」
FTPクライアント・サーバ間では、
「21番は、接続が続いてることが前提」
でなければいけません。

ところが、ここで、Coregaのルータ君ってば…
21番に、長時間、何も流れてないと、勝手に21番の接続を切っちゃう模様。
返事を渡し合うはずの21番が切れてますから…
当然、「受信成功」の返事は、FTPクライアントに届きません。

FTPクライアントは、「返事がない…」、
FTPサーバは、「『受信成功』って返事送ってるのに応答がない…」、
そして、双方共に、timeout。
張本人のルータ君は、呑気に口笛でも吹きながら、知らぬ存ぜぬを決めこんでる、と。


…………

…………

嗚呼…
…なんという親切心でしょう…

「アレ？ このポート、使ってないんじゃネーノ？
　よっしゃ！ 俺様が親切にも、接続を切ってさしあげようじゃないの！
　この優しい俺様に感謝したまえ！　わっはっは！」

とでも思って、切断してくれてるのでしょう…
あまりのありがたさに涙が…

ていうか！　余計な事してんじゃねー！！
この涙は、嬉しさの涙じゃなくて、悲しみの涙だ！ ゴルァ！！ ヽ(TДT)ﾉ

---

これは勝手な推測ですが、親切心と言うより…
21番を長時間に渡って、接続したままにできるだけのスペックが足りてない気もします ＞ Coreg BAR SW-4P

特定のポートの接続を維持する為には、おそらく関連情報を保持しておくためのメモリ容量等、必要になるのかもしれません。
しかし、FTPでのファイル転送時、データポートを介し、膨大な量のパケットが行き来してるわけで…

利用してなさそうなポートに関する情報はさっさと潰して、今現在、積極的にガンガン利用してるポートに対し、その僅かなリソースを少しでも提供したほうが、転送効率が上がる・問題が少なくなる…
そんな場面があり得る故に、あえてそういう仕様にしてる可能性もあるのかなと。

---

さて。

これらの推測が正しい… Corega BAR-SW4P が原因であったとした場合…

私は今後、何をどうすればいいのでしょうか？ (;´Д｀)

---

対策その１．まともなルータを新規購入する。

…金が無いので、必然的に却下(爆)

---

対策その２．いっそ、Linux機をルータにしてしまう。

サーバ機（ルータ）を、階下に置くことになって、
「ファンの音がウルサイ！ 眠れんだろ！」
「デカイ！　邪魔だ！」
と家族に怒られるから却下(爆)

（メインPCに比べりゃ静かなんだけどねぇ…
やっぱりファンレスとかじゃないとダメですかね、その手のは。）

---

対策その３．FTPサーバの利用を諦め、HTTPだけでUPできる環境を構築する。

今現在、設置してる、アップロードも可能な掲示板cgi…
ああいったモノを主軸に持ってくる、という感じでしょうか。

例えば、巷にある無料HPスペースなどでは、
「FTP不可」・「ブラウザでのみUP可能」
といった利用をユーザに提供してる場合も少なくありません。
そういったモノを導入できれば、FTPに対する不満も多少は改善するはず。

また、更に進んで、FTPを廃止できれば、セキュリティも今より向上します。
実際、セキュリティ関連の情報サイトでは、そういった方法を推進してる場面も少なくない…
ユーザが利用できるポートを極力排除する＝セキュリティの向上、なわけですね。

しかし、HTTPを利用したUPの場合、ファイル容量の増加と比例して、サーバの負荷が大きくなるそうで。
当方が利用してるサーバ機は一昔前どころか二昔、三昔前のスペック。
ちと荷が重くなるやもしれません。
考えてみれば、その手のサービスでは、UPできるファイル容量に制限を設けている場合がほとんど…
もしかすると、そういった理由からも、制限を設けているのでは…という気もしてきます。

また、関連スクリプト・プログラムをどこで入手すればいいのか、そのあたりも不明瞭。
果たして、そういったモノは、巷に公開されているのでしょうか。
もしかすると、有料だったりして… (T▽T)

---

対策その４．FTP利用時、ファイルを分割して転送してもらう。

容量が小さい＝1ファイルあたりの転送時間が短ければ、おそらく制御ポート（21番）も切れないでしょう。

デメリットとしては、

• UPする側が、一々分割しなきゃならない。
• DLする側が、一々結合しなきゃならない。

…うっ。
メンドクサイかも (;´Д｀)

---

対策その５．timeoutは無視して使う。

転送後のtimeoutは無視してしまう、というのも手です。
幸い、今のところ、ファイルの転送自体は上手く行ってる場合が多いので。
これが一番楽なんじゃないかなぁ… ＜ものぐさ

まあ、回線が不安定な場合、途中で切れちゃう・ファイルが壊れる可能性も、充分あり得るわけで(爆)
正常にUPできたかどうかの怪しさは、どうしても残ってしまいますが…

でも、まあ…

• 転送後、ファイルサイズを確認しておく。
• CRCファイルを用意して、それもアップしておく。

…等をすれば、ファイルの整合性チェックもある程度は解消できる…とは思います。

---

思いつくのはこのくらいでしょうか。
自分の中では、
「timeoutは無視しちゃうもんね作戦」
「メンドクサイけどひとまず分割作戦」
が、かなり魅力的だったりします (T▽T)

それにしても、失敗しました…トホホ。
安さに引かれて買うんじゃなかったです… (T_T) ＞ Corega BAR SW-4P

そういや、エレコムの安いルータも、型番は違うけど中身はほぼ同じらしいですね。
他にも、いくつかのメーカから、同じハードが売られてるとか。
その手の安物ルータを購入する場合、注意が必要なようです。

まあ、普通に利用してる分には問題無いんですけどね。
とは言っても、せめてポートの範囲指定ぐらいは可能なヤツを買ったほうが良さそうです。
サーバを立てる等々そこまでしないとしても、それらの機能の有無で、ネット関連アプリの使用に制限がつく場合がありますから…

tcpdumpの使い方、ようやくわかりましたよ (´▽｀;)
（tcpdumpについては、Google-Linuxあたりで、「tcpdump」で検索してみてください。ぞろぞろ出てきます。）

tcpdump -x -s 1600 -i eth0 port ftp -l
と打てば、
eth0（NIC）のftp(21番)ポートを流れる、1600バイト分のパケット内容をdumpする…
みたいな感じですかね。
止めるときは、Ctrl + c ですね。

このままじゃ16進の羅列ですので、Perlで適当なフィルタを作り、内容をASCII表示します。
巷のサイトにあるヤツだと、応答とASCII表示がずれるので、下のような感じにちょこっと修正。
泥くちゃーいですけど(爆) まあ、動けば官軍。

#!/usr/bin/perl
$store = "";
while(<>){
    if(m/^[ \t]/){
        chop;
        s/\t/ /g;
        s/\s//g;
        $store .= $_
    } else {
        chop;
        $tmpstr = $_;
        $_ = $store;
        s/[0-9A-Fa-f][0-9A-Fa-f]/pack("C",hex $&)/eg;
        s/[\x00-\x08\x0a-\x1f\x7f-\xff]/ /g;
        print "$_\n$store\n\n";
        $store = "";
        print "$tmpstr\n";
    }
}

if ( $store ne "" ) {
        $_ = $store;
        s/[0-9A-Fa-f][0-9A-Fa-f]/pack("C",hex $&)/eg;
        s/[\x00-\x08\x0a-\x1f\x7f-\xff]/ /g;
        print "$_\n$store\n\n";
        $store = "";
}

こいつを、tcpdumpfilter.pl とでもして保存して、
tcpdump -x -s 1600 -i eth0 port ftp -l | tcpdumpfilter.pl
みたいな。

ただ、利用してみたんですが、なんか「FTPが重い」と苦情が出てしまいました(爆)
もしかすると、

tcpdump -i eth0 port ftp -w temp.log

とでもして、一時的に生ファイル（？）で書き出し、
後から、

tcpdump -x -s 1600 -l -r temp.log | tcpdumpfilter.pl

として、出力したほうがいいのかもしれません。

---

と、上記のような実験をしてみてわかったんですが。

226＝「受信成功」は、やっぱり制御ポート（21番）を流れるようですな。

そして、今回の症状…
FFFTPがタイムアウトを、起こす・起こさないに関わらず、
ProFTPD自体は、226=「受信成功」コードを、NIC上に流してることもわかりました。
つまり、ProFTPDのバグが原因、というわけではないようです。

すると…
NICから送り出された「受信成功」のお知らせは、一体どこへ消えたのか… (･_･？)

その謎さえ解ければ、FTPクライアントがタイムアウトを起こす理由もわかりそうです。

FTP串なんて見つかりませんがな。
ていうか、探してたらどんどんUGの世界に近づいてるような… (;´Д｀)

FTP鯖公開してる人達って、HDD容量が、60Gとか80Gとか、そういう世界なのね…
ウチ、たった5G。スイマセン。何せ余りモノで作ったサーバ機なもんで (;^_^A
（ていうか、昔のハードじゃないとLinux動かないし。）
HDD追加って言っても、このヘボM/Bに、最近出回ってるHDDなんて繋がるんだろうか。
UDMA/33に設定しないとダメなんだろうけど。

ProFTPDを、1.2.1 → 1.2.4 にUpdateしてみました。

作業、大変かと思ってたけど、そんなことは無かった。
このページに書かれたとおり、解凍して、
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var/run
make
make install
と打ちこむだけでした。（configure のパラメータはVine用）


…でも、例の症状変わらず。


てことは、ProFTPD自体のバグではおそらくないのだろう、と。
全世界で利用されてるこのプログラムに、こういったバグがいつまでも残ってるはず無いだろうし。
（でも、こういう報告もあるようで…
ただ、ウチの不具合とは、容量が全然違うし、ProFTPDも凍ってないし。）

おそらくオイラの環境に起因する何かが原因なんだろう…
ハードなのか、ソフトなのか…

tcpdumpというプログラムで、TCPパケットが閲覧できるらしく。
それ使って動作をチェックしてみるつもりです。
でも、man tcpdump 読んでも、使い方がよーわかりません(爆)
日本語なのになぁ。こりゃもう少し格闘だなぁ…

FTP proxyも探さないと。
それがあれば、自分で動作実験ができる。
ちょうどいいタイミングでtcpdumpを使う必要もあるし。


LAN内のPC間でなら、容量が大きくても転送成功と言ってくる…
てことは、おそらく容量で不具合が発生するのではなく、転送時間が関係してる気が。

とすれば…
たとえ、LAN内PC間での転送でも、速度制限を加え、時間をかけて転送すれば不具合を再現できるかも。
でも、速度制限が可能なFTPクライアントなんて存在するんだろうか…

HUBやケーブルの不調も考えたんですが…
（10BASE-Tとは言え、4〜5年前で5千円しなかったぐらいの安物だし＞HUB）
でも、それならLAN内での利用自体が不安定になりそうな気がするんですが。
そういう事態は経験してないしなぁ。

相変わらずFTPでハマってます。進展無し。

tcpNoDelay on → off
tcpBackLog 5 → 20
tcpReceiveWindow 8192 → 17520
tcpSendWindow 8192 → 17520

をひっそりと指定して様子を見てたんですが、変化無しですね…

---

あちこち、さ迷ってみて、以下のような原因が考えられるかなと仮説を立ててみたり。

---

１．ルータの不具合

corega BAR SW-4Pユーザで、
「FTPしてると途中で止まってしまう」
という症状に見舞われてる事例を見かけたり。

何でも、FTPをしながら、

• 複数のPCでネットに繋ぐ
• FTP以外のネットサービスを利用
• 回線速度が遅くなる

…と発生しやすいとか。

とすれば、そもそもルータの不具合なのか。

それならばと実験。
freeweb相手に、Win機からFFFTPでUP or DLしつつ、同時にWeb閲覧してみたり。
これであっさり止まったら、ルータが原因に違いない。

偶然にも、freewebで使用してるFTPDはProFTPDの模様。
（表示されるサーバ情報を偽装してなければ…）
実験には都合がいい…

んー、UP・DL共にOKだなぁ…
すると、ルータの不具合じゃないってことか…

しかも、PORT・PASVモード共に、問題無く転送が出来てしまい、また悩んでしまう。
どうしてこのルータ、PORTモードもOKなのだろう。
上記の実験時、データポートとして1104,1105番を使ってたようだけど…
そこは、特に何も指定してない。
なのにどうして、FTPサーバから接続要求が、Win機まで届くんだろう。

FTPの時だけ、関連するポートを上手く処理してくれてるんだろうか。
21番を「PORT」が通ったら、中身を解析して、利用する予定のデータポートを開け閉めしてくれてるとか。
あるいはルータにとって都合のいいポート番号に変換してしまうとか。
だとすると、昨日のProFTPDの利用するデータポート決め打ちは無意味な指定なんだろうな。

しかし、複数のPCが同時にFTPを利用した場合、どうなるのかな。
仮に、同じデータポートを使おうとした場合、ルータはどのPCにパケットを渡せばいいのか判断できるんだろうか。
パケットの中のIPアドレス情報で判断するのかな。

うーん…謎です。
自分、FTPの仕組み・ルータの動作について、かなり色々と勘違いしてるっぽい (;´_｀)

---

２．ProFTPDのバグ

今、ProFTPDの最新Version、1.2.4なんですよね…（一昨日だかにバージョンアップ）
自分の環境で利用してるProFTPDは、1.2.1。
リリース内容文書が英文だから、何が良くなってるのかオイラにはちんぷんかんぷん。
（和訳してあっても、ちんぷんかんぷんなのでは、という話も）
ただ、結構な数のバグFIXがされてるみたい。

試しにアップデートしてみようかしら。
Vine用のRPMは出てないから、自分でコンパイルしなきゃいけないけど…

---

３．OS間でのやり取りの問題

Turbo Linux Server をカスタマイズして使ってる、某レンタルサーバサービスで、
「Win2000←→Turbo Linux のFTPが上手くできない」症状が出てる、という話を目にしたり。
大き目のファイルを転送すると反応が返ってこないのだとか。
なんか症状が似てる…

もしかすると、FTPクライアント側の利用OSによって、FTPの不具合が出る場面もあり得るのだろうか。
自分のはWindows98だから、不具合が再現できないのか。

でも、Win98とWin2000って、そのあたり具体的に何が違うんだろう。
MTUとかかな。

試しに、MTUを、Win2000のデフォルトらしい1500に設定して試してみたり。
…Win98-Linux間で問題無くFTP出来てるなぁ。
ていうか、Linux側のMTU、1500になってる。
MTUが違うと問題が起きるなら、むしろ今までの方が、不具合が起きてて当然なのでは。
それとも、LAN内はともかく、ルータを通す…WAN-LANだと結果が違ってくるんだろうか。

んー、でも、これは原因ではないような。
問題が起きてるのは、そのレンタルサーバサービスだけのようだし。
他じゃ聞かないもんなぁ。

---

４．オイラの設定(爆)

一番可能性が高いのはコレですが。

例えば、Timeout関係の設定が、どこか不適切とか…？

数十分に渡って接続してファイルをアップする…
なんて利用の仕方は、今までのナローバンド環境では想定してない使い方かもしれないし。
とすれば、
「このtimeout設定で充分。
　これ以上の接続時間は何か異常が発生してるに違いない。
　もしくは攻撃されてるかも」
と、デフォルト設定されてる部分で引っ掛かってるとか。

でも、それだったら、その旨、ログに残りそうだよなぁ…
「受信成功。データコネクションをクローズ」
なんてレスポンスコード、律儀に返すのもおかしい。

何か見落としてる設定があるのかなぁ…
ProFTPD以外の何かが関係してたりもするのかなぁ…

---

とりあえず、一つ一つ検証してみるしかなさそう。
それに、英文ドキュメントとも、もう少し格闘してみよう…

えー、そのままでは、LAN内PCからWAN経由でサーバ機にアクセスすることは出来ないのであります。

ローカルIPを直接指定すれば見れます。
一応それで各種実験・BBSにカキコ等してるわけですが。
でも、それはあくまでLAN内でのやり取り。
WAN（インターネット）を経由して正常動作してるかどうかは不明なまま…

ですから、外部のPCから繋げてもらうしか、そのへん確認手段がなかったんですが。

一応、LAN内PCからでもそのあたり確認する方法がわかりましたですよ (-_☆)キラーン
どうやら、外部のproxyサーバを通せばいいみたい。
DDNSで、オイラにも見れたでゲマ (´▽｀)

ただ…
コレ、Webサーバしか見れないんですよね… (;´Д｀)

FTP proxyサーバを通せれば、FTPサーバへのWAN経由アクセスも出来そうですが。
でも、FFFTPあたりのヘルプを読んだ限り、一般的なproxyサーバだと、

[FTPクライアント] --(HTTP)--> [proxy] --(FTP)--> [FTPサーバ]

という接続の仕方になるそうで。
一般的なFTPクライアントソフトから、FTPサーバをWAN経由で見るためには、

[FTPクライアント] --(FTP)--> [proxy] --(FTP)--> [FTPサーバ]

でないと、アカンのであります。

一応ブラウザ使って、anonymous でアクセスしてみたんですが。
見れた事は見れたんだけど、これじゃ肝心のアップ動作実験できないし…

未だ、FTPサーバ動作確認に関しては、皆さんのお力添えが必要のようです。
うううう、お手数かけてますです… (/_;)

---

FTPでハマってます。
見事にハマってます。

でも、嬉しい情報が二つ。

---

一つ目。

PORTモードでも、FTPサーバにアクセスできることが判明。
G氏の協力のおかげです。ありがとう〜 (´▽｀)ノ

まあ、元々PORTモードもOKなはず、でやってたんで…
（自分、最初の頃、PASVモードの存在を知らなかったというのが真実(爆) ）
これで一応動作することの確証は取れました。ありがたいことです。

で、それに関連して。
20番（データポート）は、ルータで開けとかなくてもOK、ってのも判りました。

そもそも、FTPサーバから見た時の20番の使い方は、

FTPサーバ : 20番 → FTPクライアント : ????番

という流れで接続要求を「出す」為に使います。
（????番には、1024〜65535の任意のポート番号が入る）
ですから、

FTPクライアント : ????番 → FTPサーバ : 20番

という接続要求を「受け付けられるよう設定しておく必要性は無かった」のでした。

---

二つ目。

PASVモードの際、本来なら、1024〜65535の任意のポート番号がデータポートとして利用されます。
で、ProFTPDで、その範囲が指定可能であると判明。

これでPASVモードを、オイラにも理解可能な状態で利用できます。
Y氏の協力のおかげです。ありがとう〜 (´▽｀)ノ

やり方は、/etc/proftpd.conf に、
PassivePorts 1240 1248
といった感じで書きます。
ポート番号は、1024〜65535の範囲。ProFTPD 1.2.0rc3 以降で利用可能らしいです。

ProFTPDの日本語ドキュメントには、そのあたり記述が無かったのですが。
このページでそういう記述を見つけ、ProFTPDの本家サイト（英語）で確認したら、確かにそういう設定が出来る模様。
範囲の指定さえ可能なら、後はルータで、該当するポートを開けておけばいいわけです。
で、Y氏のFFFTPのログで、設定通り動いてることを確認させてもらいました。

が。
ここで、corega BAR SW-4P のダメダメさが足を引っ張ります。

BAR SW-4P には、バーチャルサーバ機能という、
「ポートを一個ずつなら開けられる」機能がありまして。
ポートを開けるのに、コレ使ってるんですが。

コレ…１０個までしか設定できないんッスよ…
しかも、9600番より上の番号は設定できないとくらぁ (;´Д｀)

もし範囲指定が出来たなら、10個でもお釣りが来るんだけどなぁ…
一個ずつで10個か…あんまりだよなぁ…

結局、ICQ用に開けてたポートをいくつか潰して、FTPのデータポート用に割り振りました。
なんかもう、雀の涙のような開け方。
とは言え、これで必要最低限のポートを開けるやり方で対応できるわけで。
デンジャラス性の高いDMZ機能は使わずに済みそうです。

関係無いけど、ProFTPDの本家サイト、串通さないとアクセスできない…
OCN利用者で悪さしてるヤツが居るんとちゃうやろか ＜勝手な妄想

つか、熊本や札幌の見知らぬOCNユーザから、未だにNimdaのアクセスが来てるんですが。
知らせてやる方法ないのかな…うっとおしいんだけど。

---

といった感じで、PASVモード時のデータポート利用範囲指定は成功したんですが。
それでも、大きいファイルを転送すると、反応が返ってこないのは相変わらずのようです（涙

ProFTPDのログには、226(＝要求されたリクエストは成功した。データコネクションをクローズする)が記録されてるんですが。
（レスポンスコードに関してはコチラを参照）
FFFTPのほうは、その226を受け取れてないらしい。
というか、ProFTPDが返したつもりになってるだけなのか。
で、FFFTPが「おいおい、FTPサーバの返事がねえよ」とtimeout。
その後、ProFTPDも、「おいおい、FTPクライアント、返事したのに何も言ってこないジャン」とtimeout。
（このへん、サーバに残ったログの時系列と、Y氏の送ってくれたログ画面を見て確認しました。）

んー、226って、21番の制御ポートを使って送るのと違うのかな。
としたら、データポートどころじゃなく、肝心の21番が切れちゃってるってことなんかなぁ…
小さいファイルを送ってる分には大丈夫っぽいのに…

ん？ 小さいファイルならOK…？

もしかして、ProFTPDのバグだろうか。
ProFTPD、ついこないだまで、PASVモードがおかしいとか、5分以上ファイル転送してるとデータが化け始めるとか、そういうバグがあったそうだし。
（自分の環境は、Vine2.1.5インストール時の、ProFTPD 1.2.1 使ってるんで、バグFixされてるっぽいですが。ファイルが壊れる場面は見てないです。）

本家サイトのバグ報告関連ドキュメント（英文）と格闘してみようか…
嗚呼、それって、英語赤点のオイラには過酷な試練かもしれん… (;´Д｀)
単に自分の設定ミスであって欲しいなぁ…

FTPクライアントからFTPサーバにファイルをUP出来るけど、大きいファイルのUP直後にエラーが出る、という不具合が発生してるのであります。

ログを見たところ、
クライアントが「STOR」（＝アップロード）を送ってファイルをUP
→ サーバが受信成功コードとファイルサイズをログに記録…
そこでパタリとアクセスが無くなってる。

んー、その次の段階で、データポート接続確立が出来ない、ってパターン？
ファイル自身はしっかりきっちりちゃんと届いてるんですがね。（サーバも受信成功コードを残してるし）

LAN内のPCからはOKなんですわ。大容量のファイルでも。
ただ、LAN内ではデータポート接続確立できて当たり前でしょうし。
せいぜい、ftpdの動作に問題があるかどうか、そのへんのチェックにしかならないような。

で。
FTPの仕組みについて、もう一度調べてるんですが…よーわかりませんなぁ…

ひとまずココとかココとかココとか読んでるんですが。

読んだ限り、クライアントから「PASV」が送られてくると、サーバが「このポートを使って」と返信するのは確かな模様。そしてその返信内容は「PORT」と同様の内容らしく…
ただ、そのポートには、1024〜65535番を使うみたい。
となると…
今現在、WAN→LANのPASVモードがなぜ利用できているのか、やっぱり謎〜 (´ρ｀)

もしやルータが、イイ具合にやってくれてるのでは…
って安物ルータに過剰な期待しちゃイヤン (;^_^A
大体、そのへんちゃんとやってたら、メーカ自身が公表して宣伝に使うでしょうし。

もう少しログを残すように、ProFTPDを設定できないかな。
今現在、
「こういうのがクライアントから送られてきた。それに対してこういうコードを返した」
しかログに残ってないんですが、そこをもっと細かく、
「このポートを使うようクライアントに返した」
とか残せれば、動作が理解できそうなんですが。

でも、そんな設定、できるのかな。
とにかく調べてみないとなぁ。

---

corega BAR SW-4P、あまりよろしくないルータだったのかも (T▽T)
ネット上を漁ったら、

1. ハングする。あるいは接続が切れる。
   
2. マニュアル記載の復旧作業をすると、使用不可能と化す。
   
3. ポートの範囲指定ができない。
   

といった情報を目にしまして。
そのへんがどうもなぁ…

---

1の原因については、

• 細切れの画像ファイルを大量に読みこむとハング？
  
• ページのテーブル記述が複雑だとハング？
  
• 同時接続数を増やすとハング？
  
• 複数のPCからアクセスするとハング？
  
• WAN側の回線の速さに対して、LAN側の回線が遅いとハング？
  
• 単なる熱暴走？
  

等々色んな説があるようで。
結局、原因特定できてない模様。

とは言っても。
当方の環境では、幸か不幸か、ハングは経験してません(爆)

もしかすると最近出荷してるのは、そのへん改善してるのか…
あるいは、それら不具合の出てるユーザの製品が、密かに初期不良的要素があるのか…
って根拠無しの勝手な推測ですが。

---

2はこのへんで紹介されてますね…

---

個人的には、3が一番痛いです。

例えば、件のFTPサーバうんぬんも、TCP 1024-65535 と範囲指定できれば…
常用するかどうかはともかく（＜セキュリティ面の不安があるんで）、実験だけでも出来るんですが。
FTPサーバにしろ、ICQにしろ、苦労せずに済んだかもですね (;´Д｀)

将来的に、ファームウェアの更新でサポートされる予定も無いそうで。
というのも、搭載メモリ量の問題で、そういう仕様実装は無理らしい。

（ちなみに、搭載メモリ量が少ない事で、利用できないネット関連ソフト・ネットワークゲームもあるらしいです。
coregaのサイトのFAQでは、そう記述してあります。）

一応、DMZ機能を使って、
「WAN側からのアクセスを、LAN内の特定のPCに、全部流しちゃう」
という解決策もありそうですが…

その場合、PCの全てのポートをWANに晒すことになるし…
それにウチの環境だと、ICQ等のソフトをWindows機で利用することも出来なくなりそう。
特定のポート番号へのWANからのアクセスを、Windows機に渡してやらないといけないので。

ICQの場合、それができないと問題が出るのは、ファイル受信だけですが。
もっとも、将来的に、別のネット関連ソフトを使いたくなる可能性もあり得る。
ネットに繋がるのは、私のPCだけじゃないので。

---

まあ…ごく一般的な使用範囲において、ルータとして致命的な欠陥のある製品、というわけではないでしょうけど ＞BAR SW-4P
現にこうして、ちゃんとネットには繋がってるし (^^;
ただ、出来るなら、もう少し機能の多い製品を買ったほうが、後に色々と遊べそうではありました (T▽T)

ま、安いし。
これがcorega (;´ー｀)y-~~

昨日の日記に、
「Linux用のDDNS自動登録ツールはほとんど無い」
と書きましたが。

嘘です。大嘘です。

ちゃんと調べたらポコポコ見つかりました(爆)
日本国内向けサービスはともかく、海外のサービスでは、ちゃんと用意してるところが多かったです。

---

てことで、Linuxで自動登録処理をすべくごちょごちょ作業。
ひとまずココを参考に、no-ip.com というサービスのアカウントを取ってみました。

で、ツールをDLして解凍。コンパイル。
始めてLinux上でコンパイル・インストールしましたよ…
…って言っても、make あるいは make install と打ちこんだだけですが(爆)

---

あ、この noip というツール、ルータ使ってても大丈夫みたいです。
たぶん、cgiスクリプトを呼んで、グローバルIPを取得してるんでしょう。
（その旨設定ファイルに書いておかないと、ですけど。
　NAT=Y,PROXY=Y,DEVICE=unused だったかな？）

---

問題は、OS起動と同時に、この noip というツールを実行させる方法がわからないということ。
/etc/rc.d/rc.local に記述すればいいらしいんですけど…

よくわかんないけど、ひとまず、rc.localの一番最後に、
/usr/local/bin/noip -c /usr/local/lib/no-ip.conf
と追加してみて reboot。
ps auxgw と打ちこんで、バックグラウンドで何が動いてるか確認。
noipがちゃんと鎮座してるっぽい。
一応、/var/log/message の中にも、noipが動いてるっぽい記録が残ってる。
んー、これでいいのかな？

でも、もう少し何かをチェックしてから動かした方が良さそうな気もする。
例えば、httpd が既に動作してれば、noipも動作させる…とか。

ちなみに、/etc/rc.d/rc.local ってのは、各種デーモンが起動してから呼ばれるものみたいです。
一番最後に何かを自動実行させたい場合はここに書く…という認識で合ってるのかな？

---

ひとまずこれで、サーバ構築は終わり…かな？
もう、Linux機を動かしておけばそれだけでいい…
Windows機から、何か手を加えなければいけないことは特にないはず。

後は、今までの無料HPスペース利用と同様、スペースに何を置くか、何を設置するか、という課題だけ。

まあ、宿題はあるけど。
FTPの仕組みについて、まだちゃんと理解できてないし。
全角文字を使ったファイル名だと、どんな扱いになるのか、とか。
そのへんは、今後のんびりと調べていく事にしましょう。

とりあえず、回線速度の不安定性はさておき、
そこそこデカいサーバ容量(/home = 5GB)と、
制限の少ないCGI動作スペースは確保できた、と (´ー｀)y-~~

ダイナミックDNS（DDNS）の登録を、一定時間毎にしてくれるツールを導入してみました。
これでIPが変わってもへっちゃら (￣ー￣)ニヤリ

こちらのサイトで、いくつかツールが紹介されてますが。（GnuDIPとか）
今回はDiCEというツールを導入。

結構イイ感じかも…

ってまだIPが変わった状態になってなくて。
実際登録される場面は見てないのですが (;^_^A

---

導入するにあたって、不安だった点が2つほどありました。

1. グローバルIPを知る手段が無い。
   
2. Linux上で動くツールが無い。

---

まず、１．について。

DDNS登録をする為には、プロバイダからこちらに割り当てられた、グローバルIPを知る必要があります。

直接、PCがWAN（World Area Network）に繋がってるなら、PC自身のIP＝グローバルIPですから、難なくグローバルIPを知ることができます。
（試しに、Windows機であれば、MS-DOSプロンプトで、ipconfig[Enter]と打ち込んでみてください。今現在のIPアドレスが見れると思います（たぶん）。
Linux機なら、rootで ifconfig[Enter]…でいいのかな？ (･_･？) ）

ですが、当方の環境では、WANとLAN（Local Area Network）を結ぶために、ルータを利用してます。
プロバイダから、実際にグローバルIPが割り当てられているのは、あくまでルータです。
サーバPC自身が得られるIP（自分のIP）は、あくまでLAN内でのIP。プライベートIPです。（192.168.x.x みたいなヤツですね）
ですから、ルータに割り当てられたグローバルIPを、LAN内のPCが知る為の手段が必要になります。

まともな（？）ルータであれば、そのあたりの機能が実装されてるはずなので、それを利用すればいいでしょう。
例えば、
「telnetでルータにアクセスし、コマンド発効することでグローバルIPを得られる」
「割り当てられてるグローバルIPを表示するHTMLページが専用で用意されてる」
…等の機能があれば問題解決。
簡単なスクリプトを書いて自動処理できそうです。

しかし、当方の利用してるルータ、「corega BAR SW-4P」には、そのような機能はありません。
「ブラウザから簡単設定」を売りにしてる製品ですが、逆に言えば、突っ込んだ事は何も出来ないと言う事。
これがまともなルータであれば、「簡単設定」を用意すると同時に、そのへんもサポートしてあるもんですが…
まあ、そこが「corega」ですか。その分値段が安いし… (´ー｀;)

こういう場合、WAN（World Area Network）上の別のサーバに、アクセスしてきたIPを表示するようなCGIスクリプトを用意します。
そのスクリプトのURLにアクセスすることで、誰がアクセスしてきたのか…つまり今現在のルータのグローバルIPを知る事ができます。
（例えば、DiCEのサイトのページでも、一番下のあたりで同様のことをしてます。IPが表示されてますよね？）

今回は、DynDNS.org が用意している、その手のcgiを利用させてもらうことで解決を図りました。
（ホントは、そのサービスを利用してるわけじゃないので、実はイケナイことなのかもしれん… (-_-;) ）

---

２．について。

残念ながら、この手のツールは、ほとんどがWindows用です。
Linux上で動作するツールは見当たりません。

実際には、Perlスクリプトで同様の処理をするものも公開されてますし、開発中のLinux用ツールもあります。
つまり力量さえあれば、それらを利用してなんとかできる可能性はあるわけです。
…あくまで「力量があれば」なんですが。
ええ、そうです。タコ初心者の私にはハードルが高いんでゲマ。

しかし今回、別段Windows上から、それらツールでDDNS登録しても用は済みます。
なぜなら、Windows機から登録しようが、Linux機から登録しようが、結局はルータを介してWANに繋がってる事に代わりはないので。
どちらがやっても、結局はルータのグローバルIPが登録されます。だからひとまず問題無し。

ただ、Linux機はずっと動いてるけど、Windows機は時々電源が落ちてるんですよね。それがちと問題。
とりあえず当面は、Windowsを使ってる間、できるだけDiCEを常駐させておくことにしましょう。

---

ということで、不安点もなんとか解決しそうです (^-^;

でも、このDiCE…結構リソース食いますねぇ…
そもそもWin9x系で動かす事が前提になってないからアレですが…
普通こういうことは、WinNT系でしようとするだろうし。

また、この結果を見る限り、Win9x系使ってるユーザ自体が少数派になりつつあるようだしなぁ…

それと、スタートアップに入れると、他の常駐系ソフトが正常に起動しないことがありますね ＞DiCE
OS起動後に、手動でDiCEを起動する必要がありそうです。

---

皆様の御協力で、ようやくサーバ運用っぽくなってきました。
ありがとうございます。感謝感激です (´▽｀)


結構、Webサーバを設置するだけでも、そこそこファイル交換には使えそうな感じですね。
Upload系BBSが、これほど使えるとは思いませんでした。

ただ、Upload系BBSと一口に言っても、どれでも等しく使えるかどうかは別のようです。
例えば、巷で一番利用されてるらしい、imgboard.cgi も実験的に動作させてみたのですが、結果は芳しくありませんでした。
imgboard.cgiの場合、ファイルサイズ制限が厳しいのですね。
（一般的な設置・運用であれば、充分過ぎる制限のようです。そのへん誤解しないでくださいね。）
おそらく、エラー関係をしっかり考慮して作成されてるが故に、ファイルサイズ容量に関してシビアにならざるを得なかったのではないか…と想像しているのですが。
逆に言うと、今現在当方が利用してるBBSのCGIスクリプトは、エラー関係がどうも怪しい感も…
実際、カキコが消滅してしまった事例も起きたようですし…

また、扱うファイルサイズが大きいと、非力なサーバでは利用が厳しいそうで。どうもサーバ機のメモリの食い方が変わるらしく。
幸い、ウチの環境では、あるサイズまでは利用できているようです。
もっとも、まだ利用者が少ない事が良い方向に働いているのかもしれませんが…

そのうち耐久試験（？）なんかもしてみたい気もします。
例えば2chにURLを公開するとか…
嘘。そんな恐ろしいこと出来ないッス。一瞬で潰されそうです (T▽T)

秘匿性については問題が残りますね ＞Webサーバ利用によるファイル交換
今回のような環境の場合、どうしてもそれらファイルは、一般公開に等しい扱いです。
URLさえ知れば、誰からでもアクセスできますから。

一応、Apacheを設定することで、Webページを見る場合でもパスワード認証を求めるよう設定できるそうなので、それら機能を利用してもいいのでしょうけど。
でも、それなら、まだFTPサーバを利用したほうが秘匿性は上がる気もします。
FTPなら基本的に、ユーザ名・パスワードを知らないと利用できないでしょうし。（anonymousや、Web公開用フォルダの中は別ですけど…）
とはいえ環境によっては、昨日の日記にも書いたように、FTPサーバ設置はWebサーバ設置より少し面倒なところもありそうです。

ファイル交換手段に関しては、WinMXやICQなどを利用する…という手もあります。
そちらのほうが現実性があるでしょうね。手軽だし、秘匿性もある。
ただ、それらに比べると、こういったサーバ設置による交換は、お互いの時間帯を気にせず利用出来る、というメリットがあると思ってます。
好きな時間にUPし、好きな時間にDLする…例えば、仕事に行ってる間、PCに勝手にUP・DLさせとく…なんて使い方もできますし。
そう…モノグサ＆生活時間帯がメチャクチャな私にはピッタリかも(爆)

なんとなくですが、ゆくゆくはWindowsがこういった機能を実装するのでしょうね。共有フォルダがWAN上を介しても形成できる、みたいな。
いや、もう既にそういう機能がついてるのかもしれませんけど ＜自分、あまりそのへん勉強してないんで知らなかったり (^^;
もっともMSのことだから、セキュリティ面について不安が残りますか (;´Д｀)

なんか前回のページ、64Kbyteを突破してしまいましたよ…
ってことで、ページ分けますです (T_T)

---

TeraTermPro+TTSSHで、Windowsの画面から、Linux機にアクセスしてるんですが。
いやー、快適です。
一台のPCから何でも出来るってのは楽でいいですなぁ…

時々うっかり変なキー押しちゃってパニクることを除けば。

---

ログの分割ですけど…
Redhat系のディストリビューションでは、デフォルトでされるようになってました(爆)

デフォルトでは、
/etc/logrotate.conf
の中で、
weekly
rotate 4
と記述されてますんで、週単位で、４ファイルずつ…
約一ヶ月分は分割・保存されるように設定されてるようです。

また、Apacheのログについては、
/etc/logrotate.d/apache
の中で設定されてるようですね。

（参考ページ　１　２　３）

---

Apacheのログに、Nimda,CodeRedウイルスからのアクセスが残るのは大変うっとおしく…
で、それらアクセス記録に関しては、ログに残さないよう設定しました。

/etc/httpd/conf/httpd.conf
の中に、
SetEnvIf Request_URI "default\.ida" virus
SetEnvIf Request_URI "root\.exe" virus
SetEnvIf Request_URI "cmd\.exe" virus
CustomLog /var/log/httpd/access_log combined env=!virus
CustomLog /var/log/httpd/virus_log combined env=virus
と記述します。
上の三行で、Nimda,CodeRedからのアクセス記録の特徴を指定してます。
これで、Nimda,CodeRedのウイルスからのアクセス記録だけ、/var/log/httpd/virus_log に、分けられた形でログが残ります。

（参考ページ　１　２）

---

FTPの仕組み、PASVモードとPORTモードについて調べてました。


FTPには、PASVモードとPORTモードってのがあります。
PORTモードってのは、特にそういう名前で決まってるわけじゃなく、単にデフォルトのモードなんですが。
PASVモードという呼び名と区別し易いよう、便宜上PORTモードと呼ぶ場合もあるらしく。

FTPを利用する場合、ポートが２つ必要になる…
って認識は、ひとまず合ってたみたい。
制御ポート（TCP 21番）と、
データポート（一般的には TCP 20番、あるいは任意のポート）ですか。

制御ポートは、接続が切断されるまで、ずっと繋ぎっぱなしなんですが。
データポートは、データの送受信をすると、一旦切れちゃう。
切れた後、またやり取りするポートを決め、接続する。
繋いで切って、繋いで切って…の繰り返しだとか。
その都度、利用するポート番号が変化するそうで。

本来、「データポートも繋ぎっぱなしでいいじゃん」って話もあるそうですけど。
今現在巷にある、FTPクライアント・サーバは、切って繋いで、といった仕様らしいです。
「『データ』を送受信」という性質を考えると、そのほうがメリットがあるのだとか。

---

で、実際のFTPの流れですが。

まず、
FTPクライアントの任意のポート（？番）から、
FTPサーバの制御ポート（21番）に、
「接続したいんだけど」と要求が送られる。

今回のウチの環境では、外部から制御ポート（21番）へのパケットは、FTPサーバ機に送るようルータを設定してます。
ですからその要求は、ルータを越え、FTPサーバ機に届くと。

次に、制御ポートを使ってユーザ認証。
ユーザ名、パスワードをクライアントからサーバへ送る。
これも、上記の設定をしてあるから大丈夫。認証される。

ここまでは制御ポートを使って行われます。
で、この後が問題…
PORTモードとPASVモードで動作が違うそうで。

---

PORTモードの場合、FTPクライアントが、
「俺はこのポートを開けて待ってるよ。サーバさんのほうから、俺の方に接続してきてくれ」
と、制御ポートを介して伝え、
自分（クライアント）は、サーバがデータポートを接続してくれるのを、ひたすら待つのだそうです。

…クライアントが「受」で、サーバが「攻」ですな。
「サーバ×クライアント」の表記でいいんだっけ？ ＜よく知らない

この「何番のポートを開けとくよ」ですが、クライアントがサーバに対して「PORT」ってのを送ります。
FTPのログを見ると、
「PORT xxx,xxx,xxx,xxx,yyy,yyy」
というのが、クライアントからサーバに送れらてきてます。
xxx,xxx,xxx,xxx がIPで、yyy,yyy がポート番号。
「yyy,yyy番号のポートを使ってくれ。よろしく頼む」と。

「今日は疲れてるから口で許してくれ」
「今日は後ろでもいいぜ…（はぁと」
ってとこなんでしょうかねぇ ＜全然違うって

---

で…
どうやら昨日のY氏との接続実験では、このデータポートの接続確立が出来ず、コケちゃった模様。
ログを見ると、「PORT 〜」が送られてきた後、パタリと反応が無くなってました。

例えば、ファイル一覧の情報などは、データポートを介してクライアントに送られます。
ところが、データポートの接続が確立できてませんから、
「ファイル一覧を見ようとしたところで、FTPソフトが固まった (T_T)」
という実験結果になったのですね。

---

さて、PASVモードの場合、流れが逆になります。

FTPクライアントが、FTPサーバに対して、
「俺のほうから、サーバさんに接続するよ」
と、「PASV」を制御ポートを介して送ります。
するとサーバが、
「了解。じゃあ待ってるよ」
と、クライアントからデータポートが接続されるのを待つ状態になる。

クライアントが「攻」で、サーバが「受」ですか。

---

よく、巷である、
「ルータを導入したらFTPが出来なくなった。これじゃホームページの更新が出来ない…」
なんて話は…

おそらく、PORTモードを使ってて…
サーバからクライアントに、データポートを接続しようとしても、間にルータが居る事で、その接続が確立されなかった…
ということなんでしょうね。（たぶん）

でも、内から外へなら、ルータはポンポンとパケットを送ってくれます。
だから、クライアントが「攻」になるPASVモードにすれば問題が解決する…
…という認識で合ってるのでしょうか？ (･_･？)

---

しかし、ここまで調べて、更にわからなくなってしまいました。

昨日の実験で判ったのは、どうやらウチの環境では、
「PORTモードでは、データポートの接続確立に失敗するらしい」
という事。
その結果自体はともかく…

なぜ、接続が確立しないのか、その理由がわからない (;´Д｀)

サーバ側は、おそらく一般的に使われるデータポート＝20番を使って、クライアントの任意のポートに接続を確立しようと試みてるのではないかと。
んー、20番、開けてるよなぁ…
ていうか、ルータを使った当方の環境にしてみれば、内→外、の流れだし。
それなら問題はないように思えるのですが…

また、PASVモードならOK、というのもわからない。
調べた範囲では、PASVモードの場合、クライアント・サーバ共に、データポートとして任意のポートを使うらしいのです。
こちらにはルータが居ますから、任意のポートにめがけ送られてもルータに邪魔されて、それを受け取れないんじゃないかと思うんですが…
でも、実際には繋がってるんですよね…なぜ？ (;´Д｀)

---

ただ、あるサイトでのFTPの説明では…

PASVを受け取った後、サーバが、
「了解。じゃあこのポートを開けて待ってるからね。送ってきてくれ」
とクライアントに返して、接続されるのを待つ…といった記述も見かけました。

…であるなら、繋がる理由もわかるような。
おそらく、
「了解。じゃあ『20番』を開けて待ってるから〜」
と返してるんじゃないかと。
20番であれば、ルータを越えてくるよう設定してますから、確かに届きそう。

が、上記の説明と違い、「お互い、任意のポートを使う」と説明してるサイトもあるんですね。
一体どれが正しいのか。
それとも、単に自分の解釈・理解が間違ってるだけなのか。
いや、そうとしか思えないんですが。

ていうか自分、どうも根本的なところでの理解・知識が足りないようで。
TCPとかパケットとか、きっとそのへんがわかってれば原因が理解できるのかも…

もう少し情報を漁ってみないと、謎は解けそうにないですね… (-_-;)