Debian 上の Proftpd - ファイル転送の問題

Debian 上の Proftpd - ファイル転送の問題

私は Debian がインストールされた VPS をレンタルしています。最近、すべてのユーザーに読み取り専用アクセスを許可し、特定のユーザーにはフル アクセスを許可するために proftpd をインストールしました。

いくつかのガイドに従って proftpd (TLS 付き) を設定しました。パッシブ ポート (iptables 経由のポート 21 とそれら) のロックを解除し、匿名ログインを設定しました。

ログインすると、すべて正常です。ログインも速く、ディレクトリも高速に巡回します。ファイルをダウンロードしようとすると問題が発生します。winscp/filezilla/python はすべてファイルのダウンロードで停止し、接続が失われます (ファイルは ~1kB なので非常に小さいです)。SFTP 経由でサーバーに接続すると、問題は発生せず、速度も最大です。

何かアイデアはありますか? 私のファイルが必要ですかproftpd.conf?

アップデート:

最初のコメント (SCP について) のおかげで、いくつか情報を追加する必要があることがわかりました。

  • ファイルを匿名で表示できるようにしたいのですが、Web ブラウザー経由が最適だと思いますが、必須ではありません。
  • VPS のフォルダー全体を HDD 上のフォルダーと同期するアプリケーションをセットアップする必要があります (Python 経由で実行する予定ですが、シェル/bash でもかまいません)
  • カタログ全体または変更されたファイルのみをダウンロード/アップロードできるようにしたい
  • サードパーティのプログラムなしでこれを実行できるようにする必要があります。cmdline/bash または公式の Python ライブラリのいずれかを使用します。Windows と Fedora の両方で動作する必要があります。

私の iptables 設定:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-ssh-ddos  tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpts:60000:65535
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ftp

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-ssh (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Chain fail2ban-ssh-ddos (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

TLS をオフにし、ゲスト アカウント経由で接続し、バイナリ モードをオンにして、ポート 21 (もちろんサーバー側) で tcpdump を開始しました。その後、1 つのファイルに対して 'get' を実行し、しばらくすると「リモート ホストによって接続が閉じられました」というメッセージが表示されました。以下は ftp 入力です。

ftp> get light.cfg
200 PORT command successful
150 Opening BINARY mode data connection for light.cfg (94 bytes)
Connection closed by remote host.

ここでは、get と connection_closed が新しい行で区切られていることがわかります。

15:12:15.836468 IP (tos 0x0, ttl 119, id 30359, offset 0, flags [DF], proto TCP (6), length 67)
    83-144-76-138.static.chello.pl.54225 > vz31640.dahost.pl.ftp: Flags [P.], cksum 0x5526 (correct), seq 139:166, ack 575, win 7618, length 27
15:12:15.836636 IP (tos 0x0, ttl 64, id 50952, offset 0, flags [DF], proto TCP (6), length 69)
    vz31640.dahost.pl.ftp > 83-144-76-138.static.chello.pl.54225: Flags [P.], cksum 0x7049 (correct), seq 575:604, ack 166, win 115, length 29
15:12:15.856530 IP (tos 0x0, ttl 119, id 30360, offset 0, flags [DF], proto TCP (6), length 56)
    83-144-76-138.static.chello.pl.54225 > vz31640.dahost.pl.ftp: Flags [P.], cksum 0xd20f (correct), seq 166:182, ack 604, win 7589, length 16
15:12:15.868348 IP (tos 0x0, ttl 64, id 50953, offset 0, flags [DF], proto TCP (6), length 106)
    vz31640.dahost.pl.ftp > 83-144-76-138.static.chello.pl.54225: Flags [P.], cksum 0xba9a (correct), seq 604:670, ack 182, win 115, length 66
15:12:15.934002 IP (tos 0x0, ttl 119, id 30365, offset 0, flags [DF], proto TCP (6), length 40)
    83-144-76-138.static.chello.pl.54225 > vz31640.dahost.pl.ftp: Flags [.], cksum 0x0ccc (correct), ack 670, win 7523, length 0


15:13:15.909873 IP (tos 0x0, ttl 119, id 30372, offset 0, flags [DF], proto TCP (6), length 40)
    83-144-76-138.static.chello.pl.54225 > vz31640.dahost.pl.ftp: Flags [F.], cksum 0x0ccb (correct), seq 182, ack 670, win 7523, length 0
15:13:15.910056 IP (tos 0x0, ttl 64, id 50954, offset 0, flags [DF], proto TCP (6), length 40)
    vz31640.dahost.pl.ftp > 83-144-76-138.static.chello.pl.54225: Flags [F.], cksum 0x29ba (correct), seq 670, ack 183, win 115, length 0
15:13:15.922725 IP (tos 0x0, ttl 119, id 30373, offset 0, flags [DF], proto TCP (6), length 40)
    83-144-76-138.static.chello.pl.54225 > vz31640.dahost.pl.ftp: Flags [.], cksum 0x0cca (correct), ack 671, win 7523, length 0

答え1

設定内容を投稿してくださいiptables。FTP は動的ポート割り当てを使用するため、FTP で動作させるのは難しい場合があることに注意してください (パッシブ モードでは、クライアントがファイルをダウンロードまたはアップロードする場合、サーバーはデータ転送ストリームに動的ポートを割り当て、それをクライアントに通知し、クライアントがそれに接続することを期待します)。

これはつまり:

  1. FTP データ ストリームを検出するために Netfilter で何らかの「ステートフル」アプローチを使用する場合は、制御 FTP ストリームをデコードするための特別なカーネル モジュールをロードする必要があります。
  2. カーネルが FTP 制御ストリームをデコードできないため、これは TLS では機能しません。

SCP (および SFTP) は、制御ストリームとデータ ストリームを単一の TCP ストリームに多重化するため、正常に動作します。

同期については…まず、scpこれはレガシー プロトコルなので忘れて、代わりに SFTP を使用してください。 これクロスプラットフォームの Python SFTP 実装のようですので、おそらくうまくいくでしょう。ちなみに、Windows は SFTP フロントエンド ソフトウェアを適切にサポートしています (WinSCP については Google で検索してください)。

また、他の同期手段も検討してください。たとえば、 にrsyncは Windows ビルドがあり、これはおそらく現存するファイルシステム同期ツールの中で最高のものです。WebDAV や、RESTful な実装も検討してください。

関連情報