パッシブモードに入った後にFTPが切断されるb / cパケットが失われる
何らかの理由で、何度試行しても、クライアントがPASVコマンド（サーバーによって正しく受信される）を送信した後、サーバーの応答（227パッシブモードに入る）がクライアントに返されません。私は、Wiresharkを使用してクライアントとサーバーの両方のトラフィックを分析し、その詳細を把握しました。特に奇妙なのは、サーバーによって送信された最後のパケットが、これまでに正常に送信された他のすべてのパケットとまったく同じTCP設定）であるということです。すべて、同じクライアント、同じポートに送信されます。 、それでも何らかの理由で、この227の応答は決して通過しません。私はその理由について完全に理解しています。
クライアントとサーバーの相互作用のスクリーンショットは次のとおりです。
クライアントキャプチャ 
ご覧のとおり、PASVコマンドのACKを受信することはありません。もう一度試して、あきらめます。
サーバーキャプチャ 
ご覧のとおり、PASVコマンドを受信して応答を送信しますが、クライアントに到達することはありません。後で再送信を取得し、さらに3回応答を送信しますが、これも通過しません。次に、切断します。
他のすべてのTCPパケットが問題なくサーバーからクライアントに到達する可能性があることは想像できませんが、この特定のTCPパケットはそうではありません。= TCPヘッダーは、サーバーとの間のすべてのパケットでそれぞれ同一であるため、私の理解では、すべてのルーター、ファイアウォール、ISPなどは、パケットスニッフィングでない限り、それらを同等に処理する必要があります。
私はちょうど同じ問題に苦しんでいて、解決策を探しているときにこの質問を見つけました。私の場合、問題の原因は、サーバーの応答をFTPバウンス攻撃の可能性として検出し、接続を切断したファイアウォール（Sonic Wall）が原因でした。解決策は、FTPサーバーのパッシブ設定を変更し、PASVへの応答として内部IPアドレスを入力することでした。次に、ファイアウォールはそれを正当な回答として検出し、その回答を外部アドレスに変換してからクライアントに送信しました。そのように設定するのは非常に間違っていると感じますが、このファイアウォールと連携して機能します。
明らかな解決策：発信パケットを破壊している可能性があると思ったルーター上の何かをいじっています。 「NATALG」（ アプリケーションレベルゲートウェイ ）と呼ばれるものを無効にすると、FTPクライアントとサーバーはパッシブモードで正常に通信を再開しました。どうやらこのプロトコルスヌーピングは多くの人々に問題を引き起こします。
将来の読者のために、私のモデム/ルーターはMotorola SBG6580SurfBoardです。私のISPEastLinkの標準的な問題。このような多くの「機能」が事前構成されており、イーサネットIIフレームレベルで発信パケットが破損しているように見えるものもありました。
Windows7サーバーでまったく同じ問題が発生しました。クライアントは「227がパッシブモードに入る」パッケージを受信できませんでした。問題はサーバー側にある必要があります。すべてのファイアウォールをオフにしましたが、それでも同じ結果が得られました。ついにその理由を見つけました。ネットワーク共有センターでは、ネットワークの場所を「パブリックネットワーク」に設定することはできません。 Windowsはパブリックネットワークを信頼できないものとして扱うためです。コンピューターを接続しようとすると、リスクと見なされ、ブロックされます。 「WorkNetwork」に設定するだけで、サーバーは正常に動作します。
これはFileZillaバージョン<3.6.0.2の既知の問題だと思いますが、万が一古いバージョンを使用しますか？