FTP Passivmodus (Filezilla) Windows Server 2012 gelegentlich " 426 Verbindung geschlossen; Übertragung von "" abgebrochen

Question

Guten Morgen allerseits,

Ich hoste einen FileZilla FTP-Server (passiver Modus) auf einem WIN 2012 R2-Server, der in MS Azure gehostet wird.

FTP-Übertragungen funktionieren im Allgemeinen einwandfrei – täglich werden mehrere FTP-Uploads und -Abrufe ausgeführt.

Ich habe einen relativ großen Portbereich (Endpunkte) auf dem Azure-Portal/der Azure-Seite geöffnet, um den passiven Modus zu ermöglichen.

Gelegentlich (im Durchschnitt einmal jeden zweiten Tag) treten bei FTP-Übertragungen Probleme wie die folgenden auf:

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 

Wie erwähnt finden täglich mehrere FTP-Übertragungen (automatisch) statt und durchlaufen den über 140 Ports umfassenden Bereich, der dem FileZilla-FTP-Server zugewiesen ist (im passiven Modus).

Ich habe eine Wireshark-Aufzeichnung auf der in Azure gehosteten VM ausgeführt. Aus den Wireshark-Aufzeichnungen erkenne ich, dass die Ereignisse „426 Verbindung geschlossen“ tatsächlich mit einem RST übereinstimmen, das von der VM in Azure stammt und an den Client zurückgesendet wird, der den PASV-Befehl ausgegeben hat (d. h. im obigen Beispiel antwortet der FTP-Server auf den PASV-Befehl des Clients mit dem Port: 234,235 -> 60139; der Client versucht, einen Datenkanal zum Port 60139 zu öffnen, um die Übertragung zu starten -> der FTP-Server antwortet sofort (innerhalb von MS gemäß der Wireshark-Aufzeichnung) und gibt einen RST an den Client aus).

Ich dachte an ein Problem mit der Zuweisung temporärer Ports auf der FTP-Serverseite -> also reduzierte ich den erlaubten dynamischen temporären Portbereich des Betriebssystems, damit er sich nicht mit dem passiven FTP-Portbereich überschneidet - mithilfe des

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

außerdem habe ich dem Netsh-Stack explizit eine Portbereichsreservierung hinzugefügt, und zwar über den Befehl

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

Dennoch tritt das Problem gelegentlich weiterhin auf.

Ich habe die ausführlichen technischen Diskussionen auf dieser Website sowie in der MS Azure TechNet-Sitzung darüber gelesen, wie Azure den Status der Endpunkte überwacht (wenn sie Teil eines LB-Sets sind), aber das ist in meinem Fall nicht anwendbar, da FTP-Passivübertragungen (Abruf und Uploads) auf zufälligen Ports innerhalb des reservierten FTP-Passiv-Portbereichs im Allgemeinen einwandfrei funktionieren.

Bei Bedarf kann ich weitere Einzelheiten bereitstellen. In der Zwischenzeit wäre ich für weitere Vorschläge zur Fehlerbehebung/zur Untersuchung auf Server- und Clientseite dankbar (ich bin ziemlich sicher, dass das Problem nicht mit dem Netzwerk oder der Netzwerkkonfiguration zusammenhängt).

Ich möchte außerdem um zusätzliche Vorschläge/Tipps zur Fehlerbehebung/Untersuchung bitten, wie man Winsock bei möglichen Problemen mit der Verfügbarkeit serverseitiger Sockets debuggt.