nicht angemeldet
Hi,
Also erstmal ein bischen Grundlegendes, zum besseren Verständniss !
Vielen Dank - langsam habe ich das Gefühl, mich wenigstens in den
Grundlagen halbwegs zurecht zu finden ...
Ja ! aber da kann doch die arme dll nix dafür das eure Firewall da
nen Port zerbrezelt.
Laut http://www.clickx3.com/commands/wellknown.htm
gibt es oberhalb von 10000 noch genau sechs well-known ports -
dort liegen aber mindestens 85% aller freien Ports.
So würfelt Linux einfach geschickter, denke ich.
Kann ja sein das eine Applikation in eurem Hause in diesem Bereich
schon Ports belegt und deshalb die Firewall da dicht macht.
Ist aber nicht. (Ja, wir verwenden _auch_ eigene Ports irgendwo dort oben,
aber die kennen wir und können sie von den besagten Ports unterscheiden.
Wir wüßten, wenn wir selbst schuld wären.)
Das ist einfach eine Einstellung der Firewall, die einen Haufen Ports kennt
und bei denen die üblichen Standard-Protokolle (HTTP, FTP, Telnet etc.) als
Hack-Versuche abwehrt.
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.
Diese Ebene muß ja wohl auf dem ControlChannel laufen, weil sie den
DataChannel aushandeln will.
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)
Wahrscheinlich meine ich die - in diesen Protokoll-Ebenen bin ich nicht
zuhause.
- 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)
Genau. Diese Ebene besteht aber leider aus zwei Teilen, die einander
nicht wirklich verstehen:
- dem Portnummern-Auswürfler aus der Windows-API und
- dem FTP-Client, der nehmen muß, was er kriegt - vor allem eben immer
denselben Port.
Das ganze Problem wäre gar keines, wenn die Windows-API begreifen würde,
daß die Firewall einen Port ablehnen darf, und beim nächsten Mal einfach
einen _anderen_ Port anbieten würde - die Chance einer Kollision ist ja
gar nicht wirklich hoch, das Problem entsteht nur, weil die Client-Seite
keine koordinierte Fehlerbehandlung zustande bekommt.
(Deshalb finde ich die Formulierung, die Firewall sei schuld, ziemlich
hart - die macht doch nur ihren Job.)
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).
Passive Mode haben wir noch gar nicht ausprobiert.
Da müßte ja jeder der diversen Kollegen die Konfiguration sämtlicher
gespeicherter FTP-Verbindungen auf jedem seiner Rechner ändern!
Weia, das möchte ich nur als allerletztes Mittel einsetzen.
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.
Hm. Also müßte die Firewall für Port 21 die Antwort des Servers verstehen
und umschreiben? Wie soll sie das aber machen? Sie kann ja nicht selbst
einen Port auswürfeln, der auf dem Server gar nicht frei ist, oder?
Wenn nicht sollte die Wall darauf konfiguriert sein alles umzuleiten.
Ähnlich wie NAT (Network Address Translation) nur halt auf Anwendungs-
ebene.
Ach so: Du meinst, sie soll nach beiden Richtungen über unterschiedliche
Ports FTP sprechen? Etwa wie ein Proxy, nur auf Port-Ebene statt auf URL-
bzw. IP-Ebene? Das klingt allerdings nach einer machbaren Lösung.
(Hoffentlich kann das ihre Software auch ...)
Lösungen!
Hmmm ! Socks 4 oder 5 je nach dem was eure Firewall unterstützt.
Firewall Admin ausschimpfen !!!
Würde ich nie tun!
Der hat auch seine Vorhaben, was er kaufen darf und was nicht.
Da fällt mir noch was auf : "die Übertragung einiger weniger großer
Dateien funktioniert dagegen reibungslos. MGet"
Ich wollte damit nur sagen: Das Problem ist kein Lastproblem - die FTP-
Verbindung läuft tadellos, wenn der Port erfolgreich ausgehandelt ist.
Was heißt den MGet??? Multi Get ---> mehrere DataChannels ???
Jups habe gerade mal nachgeschaut.
Vieleicht kann die Firewall mit mehreren DataChannels nicht!?
Der FTP-Client macht meines Wissens nichts über mehrere Kanäle parallel.
Zumindest zeigt seine graphische Oberfläche während der Übertragung den
genauen Zwischenstand an (welche Datei zu wieviel Bytes etc.).
Also mal mit get probieren und den Firewall Admin nerven.
Ich kann nichts "probieren" - der FTP-Client ist nicht von uns, der
ist einfach ein Standardprodukt (das ich aber nicht entbehren kann).
Und das macht eben MGET, wie ein normaler FTP-Client das auch tut.
Huiiii !!! mir qualmt die Rübe. (immer diese Systemanalytiker):-)
Vielen Dank erst mal - das hat mir bisher am deutlichsten weiter geholfen.
Viele Grüße
Michael