皆さんおはようございます。
MS Azure でホストされている WIN 2012 R2 サーバー上で FileZilla FTP サーバー (パッシブ モード) をホストしています。
FTP 転送は通常は正常に動作しています。FTP アップロードと取得は毎日数回実行されています。
パッシブ モードを可能にするために、Azure Portal / 側で比較的広い範囲のポート (エンドポイント) を開きました。
散発的に (平均して 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 ([email protected])
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
前述のように、毎日 (自動的に) 複数の FTP 転送が実行され、FileZilla FTP サーバー (パッシブ モードで動作) に割り当てられた 140 以上のポート範囲がスキャンされます。
Azure でホストされている VM で Wireshark キャプチャを実行しています。Wireshark キャプチャから、「426 接続が閉じられました」イベントは、実際には Azure の VM によって送信された RST と一致し、PASV コマンドを発行したクライアントに送り返されていることがわかります (つまり、上記の例では、FTP サーバーはポート 234,235 -> 60139 を使用してクライアントの PASV コマンドに応答します。クライアントは転送を開始するためにポート 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
それでも、問題は時々発生します。
この Web サイトと MS Azure Technet セッションで、Azure がエンドポイントの状態を監視する方法 (LB セットの一部である場合) に関する詳細な技術的議論を読みましたが、予約済みの FTP パッシブ ポート範囲内のランダム ポートでの FTP パッシブ転送 (取得とアップロード) は通常正常に動作しているため、これは私のケースには当てはまりません。
必要であれば、追加の詳細を提供することもできますが、その間、サーバー側とクライアント側のトラブルシューティングや調査に関する追加の提案をいただければ幸いです (問題はネットワークやネットワーク構成に関連していないことはほぼ確実です)。
また、サーバー側のソケットの可用性の問題について Winsock をデバッグする方法に関する追加のトラブルシューティング、調査の提案、ヒントもお願いします。