ユーザー名は通り、パスワードも通り、クライアントは接続済みと表示します。ところがフォルダ一覧や最初のファイル転送で永遠に待ち続け、資格情報の中にそれを説明するものはありません。FTP は一覧ごと、ファイルごとに二本目の接続を開き、失敗しているのはこの二本目の接続です。ログインが証明するのは最初の会話が機能することだけです。

確認は順番に行います。それぞれが別の層を切り分けるので、異常が出た最初の項目で止めてください。

まず二つの接続を切り分ける

制御接続はサーバーの待ち受けポートでコマンドと応答をやり取りします。データ接続はディレクトリ一覧やファイル本体を運び、パッシブモードではサーバーが自分の端点を選んで PASV または EPSV の応答で通知します。ポート 21 を許可しても、データポートに到達できるかは分かりません。ログインだけ成功して一覧がすべてタイムアウトするのは、まさにこのためです。WinSCP の FTP モードの説明 がこの分離とネットワーク要件を説明しています。

クライアントが VPN の内側にある場合、データ経路は同じトンネルを通りますが、同じポリシーを通るとは限りません。

PASV 応答のアドレスを読む

詳細表示のクライアントを実行し、推測せずに応答を読みます。curl -v ftp://user@host/サーバーが望むアドレスとポートを含む PASV 行を出力し、クライアントは次にそのアドレスへ接続します。トンネルのクライアント側で意味を持たないプライベートアドレスなら、制御チャネルが健全なままデータ接続だけがどこにも行きません。

そのアドレスを、クライアントが実際に到達したアドレスと比較します。食い違いが答えであり、ふつうは NAT か、内部アドレスで設定されたサーバーに由来します。

ポート範囲とトンネルのポリシーを確認する

パッシブサーバーは設定された範囲からデータポートを割り当てるので、その範囲を VPN と経路上のファイアウォールで許可する必要があります。21 だけを許可するポリシーはログイン専用のポリシーです。サーバーを運用する人と範囲を確認し、範囲全体が同じ挙動だと決めつけずに、その中の一つのポートを試してください。

制御チャネルが暗号化されると難しくなります。中間装置が、通知されたアドレスを転送中に書き換えられなくなるからです。

EPSV や代替手段が効く場面を知る

EPSV はアドレスを別に返さずポートだけを返すため、両端が対応していればアドレス誤りの障害を排除できます。クライアントによっては、通知されたアドレスを無視して制御接続の宛先を再利用させられます。どちらも特定のトポロジー向けの正当な手段で、万能の修正ではありません。

補助ツールにセッションを検査させるためだけで TLS を無効にしないでください。動作するプロトコルを、壊れた脅威モデルと引き換えにすることになります。

一覧と転送で確認する

アドレスやポートのポリシーを変えたら、同じ VPN 経路で新しいセッションを開き、ディレクトリを一覧します。続いて小さなファイルを転送してください。サーバーによっては一覧と転送が別のコード経路を通るからです。クライアントのログで、期待するアドレスとポートへのデータ接続を確認し、バイトが届いたことを確認する。

この作業の間は、FTP と FTPS と SFTP を頭の中で分けておいてください。パッシブポートの変更は SFTP の設定ではなく、修正はプロトコルをまたぎません。

関連記事