Die FTP-Verbindung wird nach dem Eintritt in den passiven Modus getrennt. B / C-Pakete gehen verloren

Aus irgendeinem Grund, egal wie oft ich es versuche, geht die Antwort des Servers (227 Aktivieren des passiven Modus) nicht zurück zum Client, nachdem ein Client den PASV-Befehl gesendet hat (der vom Server korrekt empfangen wird). Um das herauszufinden, habe ich mit Wireshark sowohl den Client- als auch den Serververkehr analysiert. Besonders merkwürdig ist, dass dieses letzte vom Server gesendete Paket genau die gleichen TCP-Einstellungen aufweist wie jedes andere Paket, das bisher erfolgreich gesendet wurde. Es geht alles an denselben Client, an denselben Port, und doch kommt diese Antwort aus irgendeinem Grund nie durch. Ich bin völlig durchgeknallt, warum.

Hier sind Screenshots der Client- und Server-Interaktionen:

Client-Erfassung

Wie Sie sehen, erhält es nie ACK für seinen PASV-Befehl. Es versucht noch einmal und gibt dann auf.

Server-Erfassung

Wie Sie sehen, empfängt es den PASV-Befehl und sendet eine Antwort, gelangt jedoch nie zum Client. Es erhält die erneute Übertragung später und sendet die Antwort noch dreimal, aber es kommt wieder nie durch. Dann wird die Verbindung getrennt.

Ich kann mir nicht vorstellen, wie es möglich ist, dass alle anderen TCP-Pakete ohne Probleme vom Server zum Client gelangen, aber dieses spezielle TCP-Paket nicht. Die TCP-Header sind für alle Pakete zum bzw. vom Server identisch, daher sollten nach meinem Verständnis alle Router, Firewalls, ISPs usw. sie gleich behandeln, es sei denn, es handelt sich um Paket-Sniffing.

Ich habe gerade mit dem gleichen Problem gekämpft und diese Frage gefunden, als ich nach einer Lösung gegoogelt habe. In meinem Fall wurde das Problem durch die Firewall (Sonic Wall) verursacht, die die Serverantwort als möglichen FTP-Bounce-Angriff erkannt und die Verbindung getrennt hat. Die Lösung bestand darin, die passive Einstellung im FTP-Server zu ändern und die interne IP-Adresse als Antwort auf eine PASV einzugeben. Die Firewall hat es dann als legitime Antwort erkannt und die Antwort in die externe Adresse konvertiert, bevor sie sie an den Client überträgt. Es fühlt sich sehr falsch an, dies so einzurichten, aber es funktioniert in Verbindung mit dieser Firewall.

Scheinbare Lösung: Ich habe mit irgendetwas auf meinem Router rumgespielt, von dem ich dachte, dass es ausgehende Pakete beschädigt. Ich habe "NAT ALG" ( Application-Level-Gateway ) deaktiviert und der FTP-Client und -Server haben wieder die normale Kommunikation im passiven Modus gestartet. Anscheinend verursacht dieses Protokollschnüffeln vielen Menschen Probleme.

Für zukünftige Leser ist mein Modem / Router ein Motorola SBG6580 SurfBoard. Standardausgabe für meinen ISP EastLink. Es wurde mit vielen solchen "Funktionen" vorkonfiguriert und einige schienen ausgehende Pakete auf der Ethernet II-Rahmenebene zu beschädigen.

Ich denke, dies ist ein bekanntes Problem mit FileZilla Version <3.6.0.2. Verwenden Sie möglicherweise die ältere Version?

Auf meinem Windows 7-Server ist genau dasselbe Problem aufgetreten. Der Client konnte das Paket "227 tritt in den passiven Modus ein" nicht empfangen. Das Problem muss auf der Serverseite liegen. Ich habe alle Firewalls ausgeschaltet, aber es wurde immer noch das gleiche Ergebnis erzielt. Endlich habe ich den Grund gefunden. Im Netzwerk- und Freigabecenter können Sie Ihren Netzwerkspeicherort nicht auf "Öffentliches Netzwerk" festlegen. Weil Windows das öffentliche Netzwerk als nicht vertrauenswürdig behandelt. Jeder Versuch, Ihren Computer anzuschließen, wird als Risiko eingestuft und blockiert. Setzen Sie es einfach auf "Work Network" und der Server funktioniert dann einwandfrei.