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


9

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. Mehrere FTP-Uploads und -Abfragen werden täglich ausgeführt.

Ich habe eine relativ große Anzahl von Ports (Endpunkten) im Azure-Portal / auf der Seite geöffnet, um den passiven Modus zu ermöglichen.

Sporadisch (durchschnittlich einmal am 2. Tag) treten Probleme mit FTP-Übertragungen 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 (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 

Wie bereits erwähnt, finden täglich (automatisiert) mehrere FTP-Übertragungen statt, die den dem FileZilla-FTP-Server zugewiesenen Port-Bereich von über 140 abdecken (im passiven Modus).

Ich verwende eine Wireshark-Erfassung auf der in Azure gehosteten VM. Aus den Wireshark-Captures geht hervor, dass die Ereignisse "426 connection closed" tatsächlich von einer RST-Quelle in Azure abgeglichen und an den Client zurückgesendet werden, der den PASV-Befehl ausgegeben hat (dh im obigen Beispiel antwortet der FTP-Server auf der Client-PASV-Befehl 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-Erfassung) und gibt eine RST aus an den Client).

Ich dachte an ein vorübergehendes Problem bei der Portzuweisung auf der Seite des FTP-Servers -> also habe ich den zulässigen vorübergehenden Portbereich des dynamischen Betriebssystems verringert, um den passiven FTP-Portbereich nicht zu überlappen

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

Außerdem habe ich dem Netsh-Stack über den Befehl explizit eine Portbereichsreservierung hinzugefügt

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

Trotzdem tritt das Problem immer noch gelegentlich auf.

Ich habe die ausführlichen technischen Diskussionen auf dieser Website sowie in der MS Azure-Technet-Sitzung darüber gelesen, wie Azure den Endpunktstatus überwacht (wenn es Teil eines LB-Satzes ist). Dies gilt jedoch in meinem Fall nicht für passive FTP-Übertragungen (Abrufen und Hochladen). An zufälligen Ports im reservierten FTP-Bereich funktionieren passive Ports im Allgemeinen einwandfrei.

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

Ich möchte auch um zusätzliche Vorschläge zur Fehlerbehebung / Untersuchung / Tipps bitten, wie Winsock auf mögliche Probleme mit der Verfügbarkeit von Server-Side-Sockets getestet werden kann.


Ich füge dies als Kommentar hinzu, da ich nicht wirklich denke, dass es eine Antwort ist, aber haben Sie TLS / SFTP auf dem FileZilla-Server konfiguriert? Ich hatte dasselbe in Azure mit FileZilla (deshalb habe ich Ihre Frage gefunden). Während ich versuchte, das Problem zu lokalisieren, schaltete ich TLS ab. Für mich hat das das Verbindungsproblem behoben. Ich hatte genau das Verhalten, das Sie hatten, manchmal bricht die Verbindung einfach ab (oft nach dem Eintritt in den passiven Modus). Den Grund dafür habe ich allerdings noch nicht gefunden :(.
Roet

Überprüfen Sie auch, ob der im PASV-Befehl aufgeführte Port sowohl auf dem Client als auch auf dem Server identisch ist. Ich hatte dort aufgrund einer Einstellung in FileZilla in Bezug auf die externen IP-Einstellungen falsche Übereinstimmungen. Ich hatte es auf dem Auflösungsmodus anstelle des "Standard" -Modus.
Roet

Zu Ihrer Information: Ich habe das gleiche Problem gesehen. Als ich mir die Protokolle ansah, stellte ich fest, dass der 426Abbruchfehler immer ein paar Sekunden nach einer anderen Sitzung folgte und eine 550Erlaubnis verweigert wurde. Ich vermute, dass dies ein Fehler mit FileZilla ist, aber für uns bestand die Korrektur darin, den 550 zu verhindern (in unserem Fall versuchte ein Testsystem, auf den Testordner zuzugreifen, verwendete jedoch Produktionsanmeldeinformationen; wir mussten lediglich die Anmeldeinformationen dieses Systems korrigieren). .
JohnLBevan
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.