IdFTP und Ftp hinter einem Router

[DelTurbo]

Hi,

ich habe im moment folgendes problem. Ich habe einen FTP-Server hinter einem NAT hängen. Nun klappt da leider der SiteToSiteUpload nicht. "Can't open Dataconnection"

Gibt es im IdFTP ein flag was ich übersehen habe??? Oder ist das garnicht vorgesehen? z.b. ein .List konnte ich erst machen nachdem ich das flag PassiveUseControlHost gesetzt habe. Habe ich vielleicht nochwas übersehen?

Danke im Voraus

[DelTurbo]

Sorry das ich so schnell gefragt habe. Aber nach 1,5 stunden suchen passiert das schonmal das ich nachfrage.

Folgendes habe ich rausgefunden. Dreht man den kram rum, also statt

Server.SiteToSiteUpload(FTPHinterdemRouter....

nach

FTPHinterdemRouter.SiteToSiteDownload(Server....

dann klappt es. Wieso? Keine ahnung. Die befehle STOR und RETR bleiben ja gleich.

[shmia]

MACHINE 1 bis 3 können eine TCP/IP-Verbindung zu "Some Host" aufbauen.
Der Router merkt sich die IP-Adressen und Portnummern und setzt das über eine interne Tabelle um.
Umgekehrt kann "Some Host" normalerweise keine Verbindung zu MACHINE 1-3 aufbauen.
(Welche IP sollte er denn verwenden? Das Netz 192.168.x.x gibt es millionenmal auf der ganzen Welt)
Der Client "MACHINE 2" kann aber den Router anweisen, einen bestimmten Port zu ihm weiterzuleiten;
dann kann man auch aus dem Internet eine eingehende Verbindung aufbauen.
http://www.cs.bham.ac.uk/~mdr/teachi...s/figs/NAT.gif

[DelTurbo]

Das geht auch andersrum, wenn der client "weis" das es mit einem FTP hinter einem NAT redet. Oder aber der Server weis wo er ist. z.b. Serv-U gibt nach aussen nicht an das er 192.168.* ist, sondern die "wirkliche" internet ip. Es hängt also auch vom Server ab wie "schlau" der ist.

Deswegen frage ich ja ob ich ein flag vergessen habe. Oder ich habe die philosophie hinter dem SiteToSiteDownload bzw. Upload noch nicht ganz verstanden.

So wie ich das gesehen habe wird an den Server ein portcommando und dann ein SSCN geschickt. Danach das STOR. auf dem empfänger wird ein RETR geschickt. Schon eiern die los. Ich vermute mal das es mit dem portcommando zusammenhängt.

[Assertor]

Hallo,

Zitat von DelTurbo:

Folgendes habe ich rausgefunden. Dreht man den kram rum, also statt

Server.SiteToSiteUpload(FTPHinterdemRouter....

nach

FTPHinterdemRouter.SiteToSiteDownload(Server....

dann klappt es. Wieso? Keine ahnung. Die befehle STOR und RETR bleiben ja gleich.

Sieht eindeutig danach aus, dass die Ports auf dem Router erst dann geöffnet werden, wenn der "FTPHinterdemRouter" etwas anfordert. Also: Portbereich des Servers prüfen und im Router freigeben. NAT ist nicht lustig , das hat aber zum Glück nichts mit Indy zu tun.

Und: Das Du ein .List erst nach PassiveUseControlHost machen kannst zeigt, das der FTP Server nicht seine Public IP postet. Passiv und PassiveUseControlHost sind da schon richtig.

TryNATFastTrack und UseExtensionDataPort wären z.B. für neuere Commandos, insbesondere IPv4 und IPv6 Kompatibilität (EPRT, EPSV, da PORT und PASV nur für IPv4 gültig sind).

Aber das von Dir geschilderte ist schon recht eindeutig... Die meisten NATs in den meisten "Routern" ist nicht dolle um es mal nett zu sagen.

Gruß Assertor

[DelTurbo]

Jo, aber der portbereich für PASV wird ja vom server mitgeteilt. Es ist ja nicht so das der client sagt "ich will port xyz haben". Wenn der server richtig eingestellt ist und der portbereich beschränkt ist, kann man die am router durchschalten.

Wo ich noch drüber "gefallen" bin ist, das SSCN bzw. CPSV wird anscheinend zur falschen seite geschickt. Das SSCN/CPSV darf/sollte eigentlich nur auf dem "sender" ausgeführt werden. Durch dieses rumdrehen ist das nun der fall. Wieso und warum weiss ich nicht. Ich hab noch nicht richtig reingeschaut. Nur flüchtig.

Ich habe hier mal eine konstellation aufgebaut wo ein server (der empfänger) das SSCN kommando nicht kennt. Da aber der sender es kennt kann man natürlich mit ssl ein fxp machen. Es geht aber nur wie folgt....

FTPOhneSSCN.SiteToSiteDownload(ServerMitSSCN....

Andersrum geht es nicht. Da denn das SSCN an die falsche seite geschickt wird. Es wird zwar geprüft ob er SSCN kann, aber dann irgendwie verdreht bzw. die falsche seite abgefragt und an die andere seite geschickt. Das fällt natürlich nicht auf wenn beide SSCN können. Aber so kommt halt vom server die meldung zurück das er das kommando nicht kennt. (solltest du vielleicht mal überprüfen lassen)

Wie gesagt, ich habe noch nicht verstanden warum es zwei SiteToSite gibt. Ein idFTP.FXP(Source,Destination,FName,FName) Sollte meiner meinung nach ausreichend sein.

Erstaunlich finde ich mal wieder, das Indy das überhaupt kann (ja, das ist ein dickes fettes lob). Andere sachen für teuer geld können zwar eine SSL verbindung aufbauen, aber nicht darüber FXPen. bzw. die kennen einfach das SSCN nicht.

Gruss

[Assertor]

Hi,

Zitat von DelTurbo:

Jo, aber der portbereich für PASV wird ja vom server mitgeteilt. Es ist ja nicht so das der client sagt "ich will port xyz haben". Wenn der server richtig eingestellt ist und der portbereich beschränkt ist, kann man die am router durchschalten.

Richtig, muß halt nur auch gemacht werden. Passives FTP ist oft tückisch...

Erstmal etwas Cross-Linking zu Deinem anderen Post dazu:
http://www.delphipraxis.net/internal....php?p=1123145

Zitat von DelTurbo:

Wo ich noch drüber "gefallen" bin ist, das SSCN bzw. CPSV wird anscheinend zur falschen seite geschickt. Das SSCN/CPSV darf/sollte eigentlich nur auf dem "sender" ausgeführt werden. Durch dieses rumdrehen ist das nun der fall. Wieso und warum weiss ich nicht. Ich hab noch nicht richtig reingeschaut. Nur flüchtig.

Ich habe hier mal eine konstellation aufgebaut wo ein server (der empfänger) das SSCN kommando nicht kennt. Da aber der sender es kennt kann man natürlich mit ssl ein fxp machen. Es geht aber nur wie folgt....

FTPOhneSSCN.SiteToSiteDownload(ServerMitSSCN....

Andersrum geht es nicht. Da denn das SSCN an die falsche seite geschickt wird. Es wird zwar geprüft ob er SSCN kann, aber dann irgendwie verdreht bzw. die falsche seite abgefragt und an die andere seite geschickt. Das fällt natürlich nicht auf wenn beide SSCN können. Aber so kommt halt vom server die meldung zurück das er das kommando nicht kennt. (solltest du vielleicht mal überprüfen lassen)

Wie gesagt, ich habe noch nicht verstanden warum es zwei SiteToSite gibt. Ein idFTP.FXP(Source,Destination,FName,FName) Sollte meiner meinung nach ausreichend sein.

Ich habe im Moment keine FTP Server in greifbarer Nähe, die SSCN können... Aber bist Du sicher, das das SSCN an die falsche Seite geschickt wird? Hast Du mal ein Netzwerk Trace-Log von den beiden Servern und dem Client?

Zitat von DelTurbo:

Erstaunlich finde ich mal wieder, das Indy das überhaupt kann (ja, das ist ein dickes fettes lob). Andere sachen für teuer geld können zwar eine SSL verbindung aufbauen, aber nicht darüber FXPen. bzw. die kennen einfach das SSCN nicht.

Danke

Gruß,

Assertor

[DelTurbo]

Zitat von Assertor:

Aber bist Du sicher, das das SSCN an die falsche Seite geschickt wird?

Ja da bin ich mir sicher. Leider habe ich kein log davon. Und leider hatte ich noch keine zeit nachzusehen wieso er das überhaupt macht.

Nachdem was ich so gesehen habe, braucht der "empfänger" nur das STOR. Die kommandos müssen nur auf dem "sender" ausgeführt werden. Also SSCN oder aber CPSV. Das ist aber im moment nicht der fall. Es wird versucht das auf beiden seiten zu machen.

Testumgebungen:
1. glftp 2.x -> glftp 2.x klappt.
2. glftp 2.x -> Serv-U V6 klappt. (Aber nur weil er das CPSV versteht)
3. glftp 2.x -> Serv-U V4 klappt nicht da er weder SSCN noch CPSV kann. Aber trotzdem wird ihm ein SSCN geschickt.

Kurz zum Serv-U V4. Der ist FXP fähig wenn er empfänger ist. Es dürfen halt nur die kommandos nicht an ihn geschickt werden. Ein RETR reicht vollkommen aus.

Ich hoffe die "testaufbauten" helfen weiter.

Gruss

EDIT: Alle tests fanden im LAN statt.

[DelTurbo]

@Assertor,

ich weiss ja nicht wer das FXPen einbaut. Aber es ist bissl komig eingebaut.

Orginal:

Delphi-Quellcode:

  
AToSite.IOHandler.WriteLn('STOR ' + LDestFile); {do not localize}
AFromSite.IOHandler.WriteLn('RETR ' + ASourceFile); {do not localize}

Besser wäre es so zu machen.

Delphi-Quellcode:

AToSite.IOHandler.WriteLn('STOR ' + LDestFile); {do not localize}
// Hier abfragen ob der empfänger 150 zurückgegen hat. Also ob er überhaupt breit ist.
// Wenn nicht braucht man dem Sender nicht sagen "schickmal"
AFromSite.IOHandler.WriteLn('RETR ' + ASourceFile); {do not localize}

Vielleicht kannst du das ja mal weiterleiten.

Danke

[Assertor]

Hi DelTurbo,

Zitat von DelTurbo:

ich weiss ja nicht wer das FXPen einbaut. Aber es ist bissl komig eingebaut.

JP Mugaas, einer der fähigsten Entwickler, die ich kenne mit besten Referenzen. Da seh ich nichts komisches.

Zitat von DelTurbo:

Besser wäre es so zu machen.

Quellen? Auch wenn es scheinbar Sinn ergibt, kannst Du bitte auf irgendwelche Standards verweisen, z.B. RFCs? Wir setzten zu 100% die RFCs um, von daher wäre gut eine entsprechende Quelle zu haben... In der Regel handelt Indy Fehlercodes nicht selbst, sondern leitete diese entsprechend weiter.

Zitat von DelTurbo:

Vielleicht kannst du das ja mal weiterleiten.

Ja, mach ich in diesem Fall sogar. Brauchst aber nicht immer pauschal von Weiterleiten reden, so oft wie Du mir schreibst klingt das ja so, als wär' ich nur Mittelsmann oder Support-Mitarbeiter Das einzige an Deinen ganzen Threads und Mails, was ich nicht selbst erledigt hatte waren die paar Zeilen im IdIRC CCTP. Die IRC Tests, Demos, die AltNickName Implementation & D7 Tests waren ja auch von mir...

Gruß,
Assertor