nicht angemeldet
moin ....
Das scheint ja wieder richtig interessant zu werden.
Also erstmal ein bischen Grundlegendes, zum besseren Verständniss !
-----
Ich habe auf nem Rechner 65535 Ports. Davon sind Port 0-1023 für Anwendungen mit Superuser rechten reserviert. (Nach Standart)
Das FTP Protokoll ist eine Erweiterung des Telnet und arbeitet mit zwei Ports. Einem DataChannel und einem für den ControlChannel(Telnet).
Für den ControlChannel ist nach Standart Port 21 vorgegeben.
-----
Beim passiv mode versucht der Client eine Verbindung zum Server auf Port21 herzustellen. Nun bekommt er vom Server gesagt auf welchem Port der Client eine Datenverbindung(DataChannel) aufbauen darf.
aktive mode bedeutet das der Server den DataChannel zum Client aufbaut. (Wie bei Rolfs Link gut gezeigt)
Nur sind dort eben eine ganze Menge Ports "well known".
1024 ist zwar "legal", aber nicht "schlau".
Nehme ich nämlich einen UNIX-FTP-Client, dann habe ich das Problem nicht.
Das liegt daran, daß dieser mit wesentlich höheren Port-Nummern arbeitet
(so um die 37000), und so weit oben scheint es keine well-known Ports mehr
zu geben. Unsere Firewall kennt jedenfalls keine.
Windows selbst benutzt hingegen durchaus Ports in Bereichen bis zu 10000!
Das hätte sich diese Port-DLL mal besser vor Augen halten sollen - und
dann nicht so weit unten mit dem Ausliefern freier Ports anfangen sollen.
Würde sie "oben" anfangen (65536, richtig?), wäre das Problem ebenfalls
gelöst.
Ja ! aber da kann doch die arme dll nix dafür das eure Firewall da nen Port zerbrezelt. Kann ja sein das eine Applikation in eurem Hause in diesem Bereich schon Ports belegt und deshalb die Firewall da dicht macht.
ungefähr funktionieren soll (bitte um Korrekturen, falls erforderlich):
- Der Client schickt ein SYN und schlägt eine Port-Nummer vor.
- Der Server schickt ein SYN ACK und bestätigt diese Port-Nummer.
- Der Client schickt ein ACK und fühlt sich ab hier befugt, diesen
Port zum Kommunizieren nutzen zu dürfen.
Wo beim DataChannel oder ControlChannel. Beim ControlChannel kann ich mir das vorstellen aber beim DataChannel sagt der Server auf welchem Port. Indem der Client das Port Kommando schickt um zu erfahren auf welchem.
In unserem Falle sagt die Firewall dem Client nicht mal explizit, wieso
sie den Port ablehnt (dafür scheint es auf dieser Ebene gar kein Sprach-
mittel zu geben):
Du meinst die Transport Ebene oder ??? (TCP/IP)
- Der Client schickt ein SYN und schlägt eine Port-Nummer vor.
- Der Server schickt ein REJ und lehnt diese Port-Nummer ab.
- Der Client muß darauf reagieren.
Beispielsweise, indem er sich nun eine neue Port-Nummer ausdenkt.
Das geschieht doch aber eine Ebene höher in der Anwendungsebene.(FTP,HTTP)
Wie macht er das? Er könnte beispielsweise wieder die schon erwähnte
Windows-API fragen. Diese weiß natürlich nichts von der Firewall, und
vor allem kommt sie nicht auf die Idee, daß dem FTP-Client die vorhin
gelieferte Port-Nummer nicht "gefallen" hat. Es besteht also die ernste
Gefahr, daß diese Windows-API wieder dieselbe Port-Nummer liefert.
Genau das passiert auch, wie wir in den Firewall-Traces sehen können:
Der FTP-Client überträgt ein paar hundert Dateien, stößt dann zufällig
an einen well-known Port, erhält ein REJ - und versucht dann aber stur
immer wieder denselben Port, bis er irgendwann aufgibt und abbricht.
Vermutlich macht er genau das, was ich auch tun würde, nämlich einen
nächsten freien Port anfordern ... aber die API liefert ihm offenbar
ständig dieselbe Port-Nummer, weil sie nicht kapiert, was los ist.
Hmmm ! Der Client donnert gegen eine verschlossene Tür. Der Server hat dem Client aber gesagt, das er genau da hereinkommen soll. (s.oben- Der Server sagt dem Client auf welchem Port er den DataChannel aufbauen soll..... im passiv mode).
Nur scheint der FTP Server nicht zu wissen das da einer die Tür abgeschlossen hat(Firewall) und erwartet das der Client da hereinkommt.
Der Fehler liegt eigentlich (nicht nur eigentlich sondern bestimmt) bei der Firewall.
Normalerweise muss eine Firewall den ControlChannel analysieren und teilweise Kommandos verändern. Wenn der Client zu Beispiel das Port Kommando sendet, um zu erfahren auf welchen Port er den DC aufbauen darf, muss die Firewall prüfen ob der Port darf.
Wenn nicht sollte die Wall darauf konfiguriert sein alles umzuleiten. Ähnlich wie NAT (Network Address Translation) nur halt auf Anwendungsebene.
Fazit: Die Firewall ist das Problem.
Lösungen!
Hmmm ! Socks 4 oder 5 je nach dem was eure Firewall unterstützt. Firewall Admin ausschimpfen !!!
Da fällt mir noch was auf : "die Übertragung einiger weniger großer Dateien funktioniert dagegen reibungslos. MGet"
Was heißt den MGet??? Multi Get ---> mehrere DataChannels ??? Jups habe gerade mal nachgeschaut.
Vieleicht kann die Firewall mit mehreren DataChannels nicht!? Also mal mit get probieren und den Firewall Admin nerven.
Huiiii !!! mir qualmt die Rübe. (immer diese Systemanalytiker):-)
cu