匿名 FTP セッションで「ls」コマンドを使用しようとしていますが、「ls」コマンドを入力すると次のメッセージが表示されます。
200 PORT コマンドが成功しました。PASV の使用を検討してください。
そして、このようにハングします (ftp プロンプトに戻りません)。
FTP セッションを再起動してパッシブ モード (PASV を引用) に入りましたが、別の問題が発生しました: 「ホストへのルートがありません」
何か提案はありますか？
答え1
quote PASV しない想像どおりにパッシブ モードに入ります。「PASV」は永続的なモード切り替えコマンドではなく、即時コマンド (すべての転送の前に実行されるコマンド) です。
むしろ、クライアントlsファイル転送が要求されるたびに、PORT ではなく PASV を使用するように指示する必要があります。
とinetutils-ftp、 使用passiveコマンドを実行するか、またはクライアントをpftpまたはとして実行しますftp --passive。
答え2
ファイアウォールでポート 20 を開くのを忘れたときに、この問題を一度経験したことを覚えています。FTP に関連付けられるポートは通常 21 ですが、データは通常ポート 20 経由で送信されます。
ポート 20 で接続を開始するユーザーが通過できるように、クライアントとサーバーの両方でポート 20 と 21 の両方が開いていることを確認します。
答え3
何か提案はありますか？
はい、FTP は捨てましょう。
おそらく、あなたが聞きたかった答えではないと思いますが、なぜそれが実際に必要なのかを説明させてください。そうすれば、あなたもこれをやろうという気持ちになるかもしれません。別の選択肢も紹介します。
FTP は、インターネットがまだ実験的なプロジェクトだと考えられていた頃に作成されました。主要な大学や大規模な組織には、権威ある機関によって施行される行動規則があり、そのためインターネット (当時は ARPAnet と呼ばれていました) 上の人々は信頼されていました。
FTP は、クライアントが TCP 接続を使用してファイルの要求を送信するように設計されています。その後、サーバーが要求を受信し、クライアントへの別の TCP 接続を開始します。
クライアントが自分のデータを保護するためにファイアウォールを使用し始めたときに、この状況は解消されました。そのため、FTP クライアントは送信接続を行うことはできましたが、受信接続はブロックされました。
これを回避する方法はパッシブ モードです。クライアントが TCP ポート 21 を使用して要求を送信し、サーバーがランダムな TCP ポート (例: 43728) を使用して別の接続を要求し、クライアントが指定されたランダムな TCP ポート (例: 43728) を使用して 2 番目の接続を確立します。
クライアントにファイアウォールがある場合は、この方法は有効でした。多くの人が、「パッシブ モード」で FTP の問題が解決されることを知り始めました。しかし、「パッシブ モード」で実際に解決したのは、その特定の問題だけでした。サーバーに、FTP のポート 21 など、特定のポート番号でのみ着信トラフィックを許可するファイアウォールがある場合、「パッシブ モード」でも動作に必要なすべての問題が解決されるわけではありません。
理論的には、FTP サーバーのファイアウォールがトラフィックを監視し、必要に応じて別のポートを開く FTP プロキシをサポートしていれば、この問題は修正できます。多くの人は、これを設定するのが少し難しいと考えています。
より多くの組織がセキュリティを重視し、FTP を軽視するようになるにつれ、FTP が一般的に壊れつつある (つまり、FTP クライアントを使用しようとする場所から、ますます多くの FTP サーバーが使用しにくくなっている) ことがわかってきました。FTP の問題は、より広範囲に広がり始めました。
しばらくの間、人々は「パッシブ モード」が FTP の問題を解決する魔法の「万能薬」のようだと知っていました。(多くの人は FTP が機能しなくなった理由を理解していませんでした。彼らは、FTP がおかしな動きをし始めたら、「パッシブ モード」がその FTP で発生した奇妙な問題を解決するようだと知っていました。後に、「パッシブ モード」が魔法の「万能薬」であるという信念は、FTP が一般的に機能しなくなった (以前ほどうまく機能しなくなった) という別の信念に置き換えられました。多くの人々が FTP が機能しなくなった理由を理解していなかったとしても、彼らが理解していたのは、別のテクニックを試すと、人生がよりうまく機能するように見えるということでした。つまり、他のプロトコルの使用を開始することです。HTTPS アップロードが普及し始めると、人々は FTP をそれほど使用しなくなりました。
したがって、最善の解決策は、最新のインターネット セキュリティ対策では機能しない古い FTP プロトコルを実際に捨てることです。FTP はそのために設計されたものではありません。NAT は、複数のデバイスが 1 つの IP アドレスを使用できるようにするためにも使用されます。
NAT はファイアウォールによって実装されることが多いですが、セキュリティ以外の目的 (サポートされるデバイスの数を増やすなど) を持つこともあります。NAT を使用する目的が何であれ、最終的には、NAT は基本的に同じ理由で FTP 接続を切断します (接続が目的のデバイスに到達できない)。したがって、FTP も NAT をサポートするようには設計されていません。
当時、FTP はファイル転送を機能させるための単なる実験的な取り組みでした。FTP は当初の目的を達成しました。したがって、今日のインターネット設計ではうまく機能しなかったにもかかわらず、FTP の設計が悪かったわけではありません。当時、その設計は実に成功していました。FTP は、今日の一般的なテクノロジーを使用するインターネットとは異なるスタイルのインターネット向けに設計されただけなのです。
HTTP では、複数の TCP 接続ではなく 1 つの TCP 接続を使用するため、それほど多くの問題は発生しません。HTTPS、SFTP、FTPS、SCP などの安全な代替手段でも同様です。
私は別の選択肢を約束しました。それは、FTPを機能させることです。戦略には次のものが含まれます。 * クライアント側のファイアウォールでFTPプロキシを実行する * FTPサーバーのファイアウォールでFTPプロキシを実行する
問題は、接続の片側を制御できないことが多いことです。そのため、これらのいずれかがオプションではない可能性があります。
ファイアウォールを完全に削除してみるのもいいかもしれません。しかし、これはセキュリティ リスクを招く可能性があり、ほとんどの人はメリットがないと考えています。代わりに、現代のインターネットではあまりうまく機能しない古い FTP プロトコルを使用するという考えを捨て、HTTPS または FTPS (または SCP) 経由のファイル転送を使用する最新のソフトウェアを入手してください。通常、ファイアウォールと NAT のどちらでもうまく機能し、プライバシーのメリットが得られます (暗号化されていないパスワードをインターネットでブロードキャストすることは望ましくありませんよね)。
パブリック ファイルを取得しようとしている場合を除き、その場合は HTTPS または HTTP の方が簡単なルートになる可能性があります。