投稿日:2003年02月09日 作成鷹の巣

No.8323 FTPサーバへ接続するとログインまでに時間がかかる。一部接続不可のサーバもあります。



FTPサーバへ接続するとログインまでに時間がかかる。一部接続不可のサーバもあります。

No.8323 投稿時間:2003年02月09日(Sun) 09:08 投稿者名:さすらいのGさん URL:

原因の切り分けができずに、悩んでいます。
Bフレッツベーシックにて、2セッションで別々のプロバイダへ接続しています。
1)固定IP8個のサービスでルータは、YamahaRT55iを介し、Redhat7.2+proftpd-1.2.5rc1-1で構成しているサーバが1台あります。
2)DynamicIP1個で通常のプロバイダに接続しています。Redhat7.2+rp-pppoe-3.5-1でLinux自身をルータにしています。

現象その1
2)でNAT内からIPマスカレードとして外にFTPすると、何故か1)へ接続すると認証画面が出るまで30秒ほど待たされます。
AirHやその他の場所から接続すると問題なくすぐ認証画面が出ます。
iptablesのマスカレードに問題があるかと思い、2)のLinuxから直接FTPしても全く同じ症状でした。

現象その2
友人宅のWarFTP(たぶん)へ接続すると、PASVでもPORTでもListの取得で固まってしまいます。2)のLinuxから直接やっても駄目で、
他の環境からは問題なく接続できます。

ここまで来ると、原因は2)のLinuxルータかな?と思い色々情報を探してみたのですが、行き詰まってしまいました。
今のところFTP以外では全く問題なく使えています。FTPに限ってはこの2カ所だけ問題があるだけで、それ以外は全く問題がありません。

似たような症状で悩んだ経験のある方いらっしゃいましたら、アドバイスをよろしくお願い致します。

#RedhatのKernelはアップデートで最新状態になっております。


逆引きが出来ない場合が多い

No.8325 投稿時間:2003年02月09日(Sun) 10:30 投稿者名:OAK URL:

FTPで接続が遅いのは逆引きが出来ない場合が多い
使っているIPアドレスは逆引き設定は入っていますか

まずは http://sakaguch.com/PastBBS/0009/B0004933.html を参考に
IdentLookups off にしてみてください。


30秒ぐらいなら、identlookups offで間違いないでしょう。

No.8326 投稿時間:2003年02月09日(Sun) 10:48 投稿者名:おやじ URL:http://www.aconus.com/~oyaji

こんにちは。

> FTPで接続が遅いのは逆引きが出来ない場合が多い
> 使っているIPアドレスは逆引き設定は入っていますか
>
> まずは http://sakaguch.com/PastBBS/0009/B0004933.html を参考に
> IdentLookups off にしてみてください。

これだけだと駄目なケースの原因がその後判明し、下記に整理しておきました。
inetdモードでも、xinet.dの設定でOKになりますので参考にしてください。
30秒前後ならこれに間違いありません。
自分がクライアントになる場合で、相手がこの状態のサイトが結構ありますが、
113を廃棄せずに、拒否できれば速くなります。

http://www.aconus.com/~oyaji/ftp/proftpd.htm


無事解決しました。

No.8356 投稿時間:2003年02月10日(Mon) 02:27 投稿者名:さすらいのGさん URL:

> これだけだと駄目なケースの原因がその後判明し、下記に整理しておきました。
> inetdモードでも、xinet.dの設定でOKになりますので参考にしてください。
> 30秒前後ならこれに間違いありません。
> 自分がクライアントになる場合で、相手がこの状態のサイトが結構ありますが、
> 113を廃棄せずに、拒否できれば速くなります。
>
> http://www.aconus.com/~oyaji/ftp/proftpd.htm

ありがとうございます。無事解決しました。
DNSの逆引きは正しく設定できていたようですが、proftpdをxinetd経由で起動していたので、
Identlookups offの設定と、あと、log_on_success,log_on_failureの設定を指示通りに変更したら、
問題なくすぐ接続後、認証画面が出てくるようになりました。

今後の勉強のため、このあたりの動作の仕組みをもう少しつっこんで調べてみたいと思います。
友人宅のWarFTPDの方は相変わらず接続できません(リストが取得できない)が、これは相手側の
問題なのでしょう・・・ 他のFTPDに変更できないか聞いてみます。

この問題で1年くらい放置してあったのですが、解決できて気分がすっきり致しました。

ありがとうございます。


良かったですね。おやじも結構悩んだ問題でした。

No.8371 投稿時間:2003年02月11日(Tue) 00:00 投稿者名:おやじ URL:http://www.aconus.com/~oyaji

こんばんは。

> この問題で1年くらい放置してあったのですが、解決できて気分がすっきり致しました。

少しでもお役に立ててうれしいです。実はこの問題、おやじもかなり悩んでいて、放置に近い状態だったのですが、あるときクライアントのファイヤウォールで113番ポートを閉じてもすぐにつながり、何かしたか一生懸命思い出し、そういえばxinet.dを触ったなあと試験して判明した物です。
お友達の件、家庭内ではPORTもPASVも問題ないのでしょうか?一度、おやじかOAKさんFTPテストをしてみてはどうですか?少しは切り分けができると思います。WarFTPdに関しては、おやじの方でWarFTPdの日本語化パッチと動的IP環境下でのPASVモード用スクリプトを提供していますが、1.70以降PASV対応されており、多くの方がおやじの試験でもパスしています。
家庭内でPORTもPASVも問題なく外部で問題だとすると、ネットワークが問題だと思います。あくまで一般論ですが、PORTでLISTが表示されないのは、FTPの通信の仕組み上クライアント側のルータやファイヤウォールの設定問題の可能性が大きく、PASVの場合はサーバ側のルータやファイヤウォール問題の可能性が高いです。従って、両方というのが少し気になりますが。


相手の環境が分かり次第、追ってレスします。

No.8373 投稿時間:2003年02月11日(Tue) 01:58 投稿者名:さすらいのGさん URL:

友人宅の環境を聞いてみます。
確かルータは、ネットジェネシスのOpt90?こんなやつだったと思ったんですが、
不思議なことに、こちらが市販のルータでマスカレードを通して接続した場合には問題なく
接続できるということですね。
Linuxルータをゲートウェイとして通した場合だけ、PASVでもPORTでも接続できないという
ような状態です。
相手の環境が分かり次第、追ってレスしますので、よろしくお願い致します。

ちなみに、私の方はBPFTP(2000Server)でもサーバ構築していますが、
Linux上で、tcpserver+DDNSで相手を判別しながら、SafeTPで暗号化かけてそれを、
NAT内のBPFTPに通して構築していたりします。
もし、FTP関係のドキュメントを作成されているようでしたら、このあたりでもお役に
たてるかもしれません。

BPFTPでは、一部駄目文字が使えないこと以外は動作は思いですが、結構便利に使えて
いたりしてます。


Warの結果報告

No.8381 投稿時間:2003年02月11日(Tue) 19:26 投稿者名:さすらいのGさん URL:

ver 1.70だったみたいで、最新版にあげて、nat.confを設定してもらい、PASV対応にしてもらったら
一発で接続できました。これで、こちらのLinuxルータから接続できないFTPサーバはなくなりました。
原因はよく分からなかったのですが、PORTモードで接続すると、クライアントによっては接続できない
らしい・・・ということだけ^^;


linuxルータのftp対策ができていないのではないでしょうか?

No.8382 投稿時間:2003年02月11日(Tue) 19:46 投稿者名:おやじ URL:http://www.aconus.com/~oyaji

こんばんは。

> ver 1.70だったみたいで、最新版にあげて、nat.confを設定してもらい、PASV対応にしてもらったら
> 一発で接続できました。これで、こちらのLinuxルータから接続できないFTPサーバはなくなりました。
> 原因はよく分からなかったのですが、PORTモードで接続すると、クライアントによっては接続できない
> らしい・・・ということだけ^^;

表題のとおりですが、下記をiptablesに追加して起動しなおしたらうまくいきませんか。insmodのパスは
環境に合わせて下さい。

/sbin/insmod ip_nat_ftp
/sbin/insmod ip_conntrack_ftp


このメッセージの解釈は?

No.8384 投稿時間:2003年02月11日(Tue) 20:28 投稿者名:さすらいのGさん URL:

# insmod ip_nat_ftp
Using /lib/modules/2.4.18-18.7.x/kernel/net/ipv4/netfilter/ip_nat_ftp.o
# insmod ip_conntrack_ftp
Using /lib/modules/2.4.18-18.7.x/kernel/net/ipv4/netfilter/ip_conntrack_ftp.o

Kernelが2.4系になったころから、このあたりはmodulesとして自動ロードになったのだと
思っていたのですが、insmodの結果このようなメッセージが出ます。
この解釈は「既に使われているよ」ではなく「使いようにしました」と解釈するべきなので
しょうか?

insmodする前のlsmod結果

# lsmod|grep ip
ipt_state 1248 2 (autoclean)
ipt_MASQUERADE 2272 1 (autoclean)
iptable_nat 19700 1 (autoclean) [ipt_MASQUERADE]
ip_conntrack 20300 2 (autoclean) [ipt_state ipt_MASQUERADE iptable_nat]
iptable_filter 2464 1 (autoclean)
ip_tables 13696 6 [ipt_state ipt_MASQUERADE iptable_nat iptable_filter]


insmodした後のlsmod結果です。

# lsmod|grep ip
ip_conntrack_ftp 4768 0 (unused) <この行はinsmodするまでは出ていませんでした。
ip_nat_ftp 4064 0 (unused) <同上
ipt_state 1248 2 (autoclean)
ipt_MASQUERADE 2272 1 (autoclean)
iptable_nat 19700 2 (autoclean) [ip_nat_ftp ipt_MASQUERADE]
ip_conntrack 20300 3 (autoclean) [ip_conntrack_ftp ip_nat_ftp ipt_state ipt_MASQUERADE iptable_nat]
iptable_filter 2464 1 (autoclean)
ip_tables 13696 6 [ipt_state ipt_MASQUERADE iptable_nat iptable_filter]

あと、19700と20300のところに、ftp系のモジュールが追加されました。
でも、NAT内のPCからPORT接続できないのなら分かるのですが、Linuxルータ上から直接ftpコマンドを
叩いても接続できないのは、これが原因ではないですよね?
(接続できないのではなくリストの取得ができない)


localhostも動作上はマスカレードしている?

No.8386 投稿時間:2003年02月11日(Tue) 20:46 投稿者名:おやじ URL:http://www.aconus.com/~oyaji

> # insmod ip_nat_ftp
> Using /lib/modules/2.4.18-18.7.x/kernel/net/ipv4/netfilter/ip_nat_ftp.o
> # insmod ip_conntrack_ftp
> Using /lib/modules/2.4.18-18.7.x/kernel/net/ipv4/netfilter/ip_conntrack_ftp.o
>
> Kernelが2.4系になったころから、このあたりはmodulesとして自動ロードになったのだと
> 思っていたのですが、insmodの結果このようなメッセージが出ます。
> この解釈は「既に使われているよ」ではなく「使いようにしました」と解釈するべきなので
> しょうか?
>
> insmodする前のlsmod結果
>
> # lsmod|grep ip
> ipt_state 1248 2 (autoclean)
> ipt_MASQUERADE 2272 1 (autoclean)
> iptable_nat 19700 1 (autoclean) [ipt_MASQUERADE]
> ip_conntrack 20300 2 (autoclean) [ipt_state ipt_MASQUERADE iptable_nat]
> iptable_filter 2464 1 (autoclean)
> ip_tables 13696 6 [ipt_state ipt_MASQUERADE iptable_nat iptable_filter]
>
>
> insmodした後のlsmod結果です。
>
> # lsmod|grep ip
> ip_conntrack_ftp 4768 0 (unused) <この行はinsmodするまでは出ていませんでした。
> ip_nat_ftp 4064 0 (unused) <同上
> ipt_state 1248 2 (autoclean)
> ipt_MASQUERADE 2272 1 (autoclean)
> iptable_nat 19700 2 (autoclean) [ip_nat_ftp ipt_MASQUERADE]
> ip_conntrack 20300 3 (autoclean) [ip_conntrack_ftp ip_nat_ftp ipt_state ipt_MASQUERADE iptable_nat]
> iptable_filter 2464 1 (autoclean)
> ip_tables 13696 6 [ipt_state ipt_MASQUERADE iptable_nat iptable_filter]
>
> あと、19700と20300のところに、ftp系のモジュールが追加されました。
> でも、NAT内のPCからPORT接続できないのなら分かるのですが、Linuxルータ上から直接ftpコマンドを
> 叩いても接続できないのは、これが原因ではないですよね?
> (接続できないのではなくリストの取得ができない)

NATルータ越えのクライアント動作時の問題は、PORTコマンドで通知されるデータコネクションのアドレスがマスカレードされないという問題(この辺りはおやじのFTPサーバの公開に詳しく書きました)なので、FTP対策をしないとデータコネクションを使うls(LIST)やget(RETR)、put(STOR)で止まってしまいます。Linuxルータ上から直接ftpコマンドを叩いても接続できない理由は良くわかりませんが、iptablesの設定が効くので、動作上はlocalhostからマスカレードしている動きなのではないでしょうか?(これは自信ありません)


ありえるかもしれません、ちょっと検証してみます。

No.8426 投稿時間:2003年02月14日(Fri) 05:42 投稿者名:さすらいのGさん URL:

>iptablesの設定が効くので、動作上はlocalhostからマスカレードしている動きなのではないでしょうか?(これは自信ありません)

これはありえるかもしれません、ちょっと検証してみます。

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

現在は、マスカレードの設定はこの一行なんですが、localhostからはマスカレードさせたくない場合は、
sourceでプライベートアドレスの範囲を指定してあげればいいだけなんでしょうか?


|目次|掲示板|過去ログ目次|▲頁先頭|