ConoHa VPS移設記 ⑨ Vsftpd

MIGRATION ROADMAP — 全17工程

① SSH、ユーザー追加
② IPv4/IPv6追加、netplan、ufw
③ Apache2
④ Let's Encrypt
⑤ PHP
⑥ MariaDB
⑦ WordPress
⑧ Dovecot、Postfix
⑨ Vsftpd
⑩ Python
⑪ llama.cpp、ChromaDB
⑫ Anaconda、Keras、TensorFlow
⑬ Node.js
⑭ MongoDB
⑮ Mosquitto
⑯ RabbitMQ
⑰ Supervisor

01インストールと旧設定の棚卸し

$ sudo apt update $ sudo apt install vsftpd

旧サーバーのvsftpd.confを見比べて、2点の見直しを決めた。

古いSSL/TLSプロトコルが有効なままだった ssl_sslv2=YES・ssl_sslv3=YES・ssl_tlsv1=YESが設定されていた。SSLv2・SSLv3はとうに破られている脆弱なプロトコルで、TLS1.0も主要な基準で非推奨。TLS1.2以上のみを許可する構成に変更した。

もう1点、旧サーバーではポートを13021という非標準ポートにしていたが、新サーバーではデフォルトの21番に戻すことにした。

02IPスコープの制約：全アドレスかワイルドカードか

③⑧と同様、「標準IPだけで待ち受けたい」という要望があったが、vsftpdには制約があった。 listen_ipv6=YES（IPv6ワイルドカード「::」経由でIPv4も一緒に受け付ける仕組み）は、特定の1つのアドレスに絞った瞬間、片方のプロトコルを受け付けられなくなる。両方を個別の特定アドレスに絞るには、vsftpdを2プロセス・2設定ファイルに分ける必要がある。

今回は個人利用のFTPということもあり、vsftpd自体は全インターフェースで待ち受けたまま、ufw側で標準IP宛の接続だけ通す方式（構成をシンプルに保てる）を選んだ。

$ sudo ufw allow to 標準IPv4 port 21 $ sudo ufw allow to 標準IPv4 port xxxxx:xxxxx proto tcp $ sudo ufw allow to 標準IPv6 port 21 $ sudo ufw allow to 標準IPv6 port xxxxx:xxxxx proto tcp

ufwの落とし穴単一ポート（port 21）はプロトコル省略可だが、範囲指定（port xxxxx:xxxxx）ではproto tcpの明記が必須。省略するとERROR: Must specify 'tcp' or 'udp' with multiple portsになる。

03つまずきの連続

service failed（起動失敗）

FileZillaから接続するとECONNREFUSED。調べるとvsftpdサービス自体が起動に失敗していた。

$ sudo vsftpd /etc/vsftpd.conf 500 OOPS: unrecognised variable in config file: ssl_tlsv1_1

vsftpd 3.0.4以降、ssl_tlsv1_1・ssl_tlsv1_2・ssl_tlsv1_3のようにアンダースコア付きだったオプション名が、 ssl_tlsv11・ssl_tlsv12・ssl_tlsv13（数字の前のアンダースコアなし）へ変更されていた（ドキュメント化されないまま変わった経緯があるらしい）。全て修正して解決。

「FTP over TLSがサポートされていないセキュアでないサーバーです」

起動はしたが、今度はFileZillaがTLS非対応と判定して接続を拒否。平文のFEATコマンドで機能一覧を直接確認したところ、原因が分かった。

$ printf 'FEAT\r\nQUIT\r\n' | nc 標準IPv4 21 211-Features: EPRT EPSV MDTM PASV REST STREAM SIZE TVFS 211 End

AUTH TLSが一覧に出ていない。これはvsftpd 3.0.5系で報告されている既知の表示不具合で、TLS1.2/1.3のみを有効にした構成だと、実際のTLS処理自体は正常でもFEATの機能一覧に反映されないというもの。FileZillaはこのFEAT応答を見てから接続方式を判断するため、「非対応」と誤判定していた。

FileZilla側の暗号化設定を「利用可能な場合は明示的なFTP over TLSを使用」から「明示的なFTP over TLSが必要」に変更したところ、FEATでの事前確認を経ずにAUTH TLSを直接試行するようになり解決。ssl_tlsv1=YESで表示バグを回避する案もあったが、実際にはTLS1.0を有効化しない今のままで対応できた。

530エラーとスマホでの接続失敗

その後、530（ログイン失敗）らしきエラーと、外出先のスマホアプリでの接続失敗が続いた。途中で検討したものの結局違った候補：

ポート20の未開放 → パッシブモードのみを使う構成では発信元ポート20は使われないため無関係
ホームディレクトリの「その他」権限 → ネット上の古い情報にあったchmod o-w系の対処は、allow_writeable_chroot=YESで既に回避済みの別のチェック（chrootルートの書き込み可否）に対するもので、今回とは無関係だった

スマホのモバイル回線では、Explicit FTPSの「途中から暗号化に切り替わる」という変則的な通信パターンが、キャリアの透過プロキシに異常とみなされ切断されている可能性が高く、これはサーバー側の問題ではないと判断して保留にした。

真の原因：旧サーバーconfの「残り香」

解決そもそもの指示は「新サーバーのテンプレートに必要な項目を足す」だったが、途中から旧サーバーのconfをコピーして直す方式に変わってしまっていた。テンプレートから改めて必要な項目だけを足す方式に組み直したところ、スマホアプリでの接続も含めてあっさり成功した。個別に確認した項目以外にも、旧サーバー特有の何かが影響していたと考えられる。

04最終版 /etc/vsftpd.conf（抜粋）

/etc/vsftpd.conf

local_enable=YES write_enable=YES local_umask=022 chroot_local_user=YES rsa_cert_file=/etc/letsencrypt/live/ドメイン/fullchain.pem rsa_private_key_file=/etc/letsencrypt/live/ドメイン/privkey.pem ssl_enable=YES ssl_sslv2=NO ssl_sslv3=NO ssl_tlsv1=NO ssl_tlsv11=NO ssl_tlsv12=YES ssl_tlsv13=YES force_local_logins_ssl=YES force_local_data_ssl=YES allow_anon_ssl=NO require_ssl_reuse=NO ssl_ciphers=HIGH force_dot_files=YES pasv_enable=YES pasv_min_port=xxxxx pasv_max_port=xxxxx allow_writeable_chroot=YES

副産物 seccomp_sandbox=NOを入れなくても正常動作した。旧サーバーではSSL有効時のseccompサンドボックスとの既知の衝突を避けるために無効化されていたが、新しいバージョン・カーネルでは問題が解消されており、セキュリティ機能を余計に無効化せずに済んでいる。

05ここまでの状態

SSLv2/SSLv3/TLS1.0を無効化し、TLS1.2以上のみを許可する構成に更新
ポートは13021から標準の21番へ変更
IPスコープの絞り込みはufw側（標準IP限定）で対応
3.0.4以降のオプション名変更、FEAT応答の表示バグなど、バージョン間の差異を複数解消
最終的に新サーバーのテンプレートから組み直したことで、スマホアプリからの接続も含めて動作確認済み