FTPパッシブモード（Filezilla）Windows server 2012時折「426接続が閉じられました。「」の転送が中止されました

皆さんおはようございます

MS AzureでホストされているWIN 2012 R2サーバーでFileZilla FTPサーバー（パッシブモード）をホストしています。

FTP転送は通常、正常に機能しています。いくつかのFTPアップロードと取得が毎日実行されています。

Azureポータル/サイドで比較的大きな範囲のポート（エンドポイント）を開いて、パッシブモードを可能にしました。

散発的に（平均して2日に1回）次のようなFTP転送の問題が発生します。

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file1

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071048

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file2

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071048

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file3

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071050

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> CWD dev_updates/Infrastructure/folder

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 250 CWD successful. "dev_updates/Infrastructure/folder" is current directory.

8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> PASV

8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> 227 Entering Passive Mode (104,40,Y,X,234,235)

8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> 426 Connection closed; aborted transfer of ""

8/8/2016 9:10:01 AM - USER_FILEZILLA (62.154.Y.X)> disconnected.

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> Connected on port 21, sending welcome message...

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220-FileZilla Server 0.9.57 beta

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220-written by Tim Kosse (tim.kosse@filezilla-project.org)

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220 Please visit https://filezilla-project.org/

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> USER USER_FILEZILLA

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 331 Password required for

前述のように、毎日（自動）で行われ、FileZilla FTPサーバー（パッシブモードで動作）に割り当てられた140以上のポート範囲をスイープするFTP転送がいくつかあります。

AzureでホストされているVMでWiresharkキャプチャを実行しています。Wiresharkのキャプチャから、「426 connection closed」イベントが実際にはAzureのVMから供給されたRSTと一致し、PASVコマンドを発行したクライアントに送り返されていることがわかります（つまり、上記の例では、FTPサーバーはポートを使用したクライアントPASVコマンド：234,235-> 60139;クライアントは転送を開始するためにポート60139へのデータチャネルを開こうとします-> FTPサーバーがすぐに応答します（Wiresharkキャプチャに従ってMS内で）RSTを発行しますクライアントに）。

FTPサーバー側のエフェメラルポート割り当ての問題をいくつか考えたので、動的OSのエフェメラルポートの許容範囲を減らして、FTPパッシブポートの範囲と重複しないようにしました。

netsh int ipv4 set dynamicport tcp start=49152 num=10000

また、コマンドを使用して、ポート範囲の予約をnetshスタックに明示的に追加しました

netsh int ip add excludeportrange protocol=tcp startport=60000 numberofports=141 store=persistent

それでも、問題はまだ時々発生しています。

このウェブサイトとMS Azure technetセッションで、Azureがエンドポイントのステータスを監視する方法（LBセットの一部である場合）に関する広範な技術的ディスカッションを読みましたが、私の場合、これはFTPパッシブ転送（取得とアップロード）には当てはまりません。予約されたFTPパッシブポート範囲内のランダムなポートでは、通常は正常に動作しています。

必要に応じて、追加の詳細情報を提供できます。当面は、サーバーとクライアント側のトラブルシューティング/調査に関する追加の提案に感謝します（問題がネットワークまたはネットワーク構成に関連していないことを確認してください）。

また、サーバー側のソケットの可用性に関する問題についてwinsockをデバッグする方法について、トラブルシューティング/調査の提案/ヒントの追加をお願いしたいと思います。

ftp filezilla azure

— オットオット
ソース

これは答えではないと思うので、コメントとして追加しますが、FileZillaサーバーでTLS / SFTPを構成しましたか？私はAzureでFileZillaを使用して同じことをしました（そのため、あなたの質問を見つけました）。問題を特定しようとしているときに、TLSをオフにしてしまいました。私にとって、それは接続の問題を修正しました。私はあなたが持っていた正確な振る舞いをしました、時々接続がちょうど落ちる（しばしば「パッシブモードに入った後」）。私はかかわらず、この原因を見つけるには至っていない:(。

— Roet

また、PASVコマンドにリストされているポートがクライアントとサーバーの両方で同じであるかどうかを確認してください。外部IP設定に関するFileZillaでの設定が原因で、不一致がありました。「デフォルト」モードではなく、解決モードで使用しました。

— Roet

参考：同じ問題を見ました。ログを見ると、426中絶エラーは常に、別のセッションから数秒遅れて550アクセス許可拒否エラーが発生することがわかりました。これはFileZillaのバグだと思いますが、私たちの修正は550を防ぐことでした（この場合、テストシステムはテストフォルダーにアクセスしようとしましたが、本番の資格情報を使用していたため、そのシステムの資格情報を修正するだけで済みました）。。

— JohnLBevan