FTP Zugang erstellen - Server hosten

entschuldigt bitte, aber ich bekomme das einfach nicht hin :(
ich habe Personal Websharing aktiviert und kann auch intern auf dem localhost die apache seite sehen. Am router habe ich port 20, 21, 22 80 und 8080, so wie 1982 freigegeben. Ausserdem habe ich via Terminal die Schrite wie auf http://www.powermaki.de/ beschrieben durchgeführt... Jedoch ohne Erfolg.
Mein Router: Netgear CableRouter RP614v2
lokale Ip des Routers ist die 192.168.0.1, die IP des Rechners, der DAV bereitstellen soll die 192.168.0.2. Via IP-Reservation im Routersetup hat mein Rechner immer diese Ip. In der httpd.conf habe ich bereits das "listen" auf die lokale ip des routers gesetzt. Alles jedoch ohne Erfolg...
Nun bin ich also ratlos und hoffe, ihr könnt mir helfen :(

Noch Angaben zu meinem System:
G5 dual 1,8 - 1,25GB Ram - Tiger 10.4.2
 
Zuletzt bearbeitet:
G5dualChefe schrieb:
entschuldigt bitte, aber ich bekomme das einfach nicht hin :(
ich habe Personal Websharing aktiviert und kann auch intern auf dem localhost die apache seite sehen

Hast Du in der Firewall-Einstellung des Sharing-Kontrollfeldes auch Port 80 freigegeben?

Am router habe ich port 20, 21, 22 80 und 8080, so wie 1982 freigegeben.

Es muss nicht nur freigegeben sein, sondern auch auf Deine feste IP hinter dem Router (192.168.0.2) weitergeleitet werden.

In der httpd.conf habe ich bereits das "listen" auf die lokale ip des routers gesetzt.

Das funktioniert nicht, er muss entweder auf allen IPs oder auf der des Rechners (192.168.0.2) lauschen. Auf IPs, die nicht zu dem Rechner geroutet werden, zu lauschen, ist sinnfrei.
 
oneOeight schrieb:
RFC 1579 und selbst RFC 3027 (NAT) erwähnen das aber, also kann es kein gerücht sein
Kannst du die entsprechende Stelle zitieren? Port 20 ist nach meinem Kenntnisstand der Quellport den der FTP Server im Active Mode für den Datenkanal verwendet. der muss also von innen offen sein (was bei der Mac OS X Firewall standardmäßig der Fall ist).
Abgesehen davon verhalten sich die meisten FTP Clients nicht rfc konform (wobei ich zugeben muss, dass ich hierzu keine Details kenne)
----------------------
dannycool schrieb:
...
Ihr habt da ein Mistverständnis. Port 20 muss nie von außen offen sein, da die Verbindungen bei denen Port 20 beteiligt sind, vom Server von *dessen* Port 20 ausgehen. Es kommt also keine neue Verbindung zu Port 20 herein.
...
Mein Reden.
dannycool schrieb:
...
Gleichwohl muss natürlich die Antwort an diesen Port zurück dürfen, so dass man einer Firewall ohne SPI, hinter der ein FTP-Server steht, durchaus sagen muss, dass sie Pakete an Port 20 durchlassen soll.
Üblicherweise lässt man Verbindungen mit dem Status "established" zu, dann muss man sich um einzelne Ports nicht kümmern, wenn die Verbindung von innen iniziiert wurde. So macht das auch die in Mac OS X integrierte ipfw in der Standardeinstellung.
Man will ja schließlich auch Surfen könne, Emails abrufen und versenden etc. :D.
dannycool schrieb:
...Bei NAT ergibt sich mit FTP ein ganz anderes Problem in diesem Zusammenhang, der NAT-Router muss nämlich wissen, dass er die von Port 20 ausgehende Verbindung vom Server an den eigentlich Client zustellen muss. Das kann er nicht automatisch ohne dass es ihm jemand erklärt hat. Hier hilft Port 20 bei der Zuordnung durchaus sogar.
Nein, das ist mW nicht so.
Der Server kennt doch die IP Adresse des Clients aufgrund der Verbindung, die dieser nach Port 21 aufgebaut hat. Mithilfe dieser IP Adresse verbindet er sich mit dem Client.
Dabei versucht er als Zielport den Quellport der Verbindung auf dem Steuerkanal + 1 zu verwenden. Das Problem ist eher, dass die Antwortpakete des Clients an den Port 20 des Servers "genattet" werden muss.
Das ist deswegen problematisch, weil nicht vorher bekannt ist, welche Quellports die Clients auf dem Steuerkanal verwenden und mit welchem Zielport der Server letztendlich erfolgreich den Datenkanal zum Client einrichten kann (der oben erwähnte Versuch kann fehlschlagen, wenn der Port am Client bereits besetzt ist).
Aus diesem Grund hilft es mW auch nicht, den Port 20 ganz zu öffnen, es genügt bei Active FTP völlig, den Port 20 für Pakete mit "established" Bit durchlässig zu halten. Im Fall von Passive FTP wird der Port 20 überhaupt nicht verwendet.

dannycool schrieb:
...Das Problem wird aber normalerweise durch Verwendung des Passivmodus umgangen, bei dem alle Verbindungen vom Client ausgehen und Port 20 auch nicht mehr vorkommt.
Womit das Problem beim Einsatz von NAT Geräten auf beiden Seiten nur von der Client- auf die Serverseite verschoben wird.

Fazit:
Das Grundproblem besteht bei FTP meiner Erfahrung nach darin, dass die Einrichtung des Datenkanals Verbindungen aug nicht vorhersehbaren Ports erfordert.
Wer das untersuchen möchte, kann dies mithilfe eines guten Pacetanalyzers und/oder einer Firewall mit Logging mehr oder weniger leicht nachvolllziehen.
 
Zurück
Oben Unten