FTP-Server nur über LAN möglich, NICHT über Internet?!

Erstmal hallo,

ich bin neu hier und erst seit kürzester Zeit Linux-User (also bitte nicht auslachen). Ich fahre hier ein Heim-LAN mit 2x WinXP Clients und einem File-, Drucker- und eigentlich auch FTP-Server. Dieser lief bis vor kurzem ganz gut mit Windows 2000. Seit etwa einer Woche bin ich auf openSuse 10.2 umgestiegen und bisher auch ganz glücklich damit, via Samba laufen Datei- und Druckerfreigabe schon sehr schön. Aber nun mein Problem:

Ich bekomme übers Internet keinen Zugriff auf den FTP-Server. Gebe ich direkt im Browser eines WinXP-Clients ftp://<serverIP> ein, ist alles kein Problem, das läuft prima.

Aber sobald ich ftp://<dyndns-name> eingebe, fängt es an: Das Dyndns-Forwarding geht, es lief ja auch bisher immer ohne Probleme. Ich komme sogar bis zur FTP-Anmeldung. Gebe ich schließlich Name und Kennwort ein, loggt er mich sogar ein, aber beim Zugriff auf das Homeverzeichnis sagt mit IE7: "Die Webseite kann nicht angezeigt werden". Firefox gibt folgenden Fehler aus: "151 5001". 5001 ist einer der freigeschalteten Passiv-Ports (5000-5100), mit 151 kann ich nichts anfangen. Versuche ich es über Filezilla Portable, kommt folgende LOG:

Status: Connecting to <DYNDNS-ADRESSE>...
Status: Connected with <DYNDNS-ADRESSE>. Waiting for welcome message...
Response: 220 Welcome to the ZOO!
Command: USER Markus
Response: 331 User name okay, need password.
Command: PASS ***
Response: 230 User logged in, proceed.
Command: SYST
Response: 215 Unix DataType: L8
Command: FEAT
Response: 211-Supported extensions:
Response: CLNT
Response: LANG EN*
Response: APSV
Response: EPRT
Response: EPSV
Response: LPRT
Response: LPSV
Response: SPSV
Response: XCUP
Response: XMKD
Response: XPWD
Response: XRMD
Response: MDTM
Response: SIZE
Response: XCRC
Response: XMD5
Response: SITE ZONE
Response: SITE PSWD
Response: MLSD
Response: MLST
Response: UTF-8
Response: UTF8
Response: 211 End
Command: CLNT FileZilla
Response: 200 Command OK.
Command: OPTS UTF8 ON
Response: 202 Command not implemented, superfluous at this site.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/"
Command: TYPE A
Response: 200 Command OK.
Command: PASV
Response: 227 (192,168,178,230,19,138)
Command: LIST
Response: 151 5002
Response: 425 Can't open data connection.
Error: Could not retrieve directory listing

Mein Server:
VIA-mini-ITX,
Suse 10.2 mit KDE
FTP-Server: jscape secure ftp-server community edition (habe vorher mit gleich geringem Erfolg auch vsftpd und pureftps probiert und finde jscape als Windows-Umsteiger VIEL einfacher zu konfigurieren)
Samba für die Anbindung der Windows-Clients
Firewall nicht aktiviert (!)
Portfreigabe der Fritz-Box: 21 (FTP) und 5000-5100 für passive mode auf lokale Server-IP.
Keine weitere Firewall im Weg.

LAN-Aufbau:
Fritz-Box seit Systemwechsel über DLAN (Devolo Powerline Adapter)
-> Switch
-> PC Win2k ->PC Win2k ->Server Suse

Kann es denn sein, dass es am passive Mode scheitert? Wenn ich lokal direkt auf die Ip des Servers logge, klappt es ja, hier wird doch auch nur Port 21 benutzt, wenn ich mich nicht irre? Und warum ging es mit W2k, aber nicht mit Linux?! :roll:

Andere Frage: Könnte etwa die Devolo PowerLAN-Brücke die passive Ports oder das FTP-Protokoll blockieren?! Mein PowerLAN funktioniert eigentlich bestens, aber die Idee kam mir jetzt gerade in den Kopf, vom Umstiegszeitpunkt her könnte es passen.

Ich wäre Euch sehr dankbar, wenn Ihr mir weiterhelfen könntet, Ich bastel jetzt schon seit Tagen stundenlang daran rum und verzweifle bald! :wtf:

Viele Grüße,

Markus


EDIT:
Ich habe gerade ausprobiert, vom Server aus über den Umweg Internet auf sich selbst per FTP zuzugreifen. Im Firefox kommt dann wieder "151 5000", aber mit dem Konqueror komme ich drauf! Wie kommt denn das nun wieder?!

High!

poste mal die Konfig deines FTP-Servers. Es könnte sein, das hier eine Security Einstellung zuschlägt. Poste ebenfalls /ets/hosts.allow und /etc/hosts.deny

Nukem36

Ich glaube, du musst mit dem Broser über ein Proxy.

Alternativ testen
http://www2ftp.de/

Sieht aber nach einem 0815-NAT-Issue aus.

dariuszmarek schrieb:

Alternativ testen
http://www2ftp.de/

Zum Vergrößern anklicken....

Hallo,

danke schon mal für die Unterstützung. Aus unerfindlichen Gründen komme ich über www2ftp drauf (active mode! Aha...). Übrigens komme ich auch mit dem IE/ drauf, wenn ich passives FTP in den Optionen deaktiviere. Wieso brauch ich denn einen Proxy?! :shock:

Also der Server ist wie folgt konfiguriert:
lokale IP 192.168.178.230
Port 21 (entsprechend geforwardet in der Fritzbox)
type: regular
private key: rsa
passive IP: 192.168.178.230
psve port range: 5000 - 5100 (entsprechend geforwardet in der Fritzbox)



hosts.allow:


# /etc/hosts.allow
# See 'man tcpd' and 'man 5 hosts_access' for a detailed description
# of /etc/hosts.allow and /etc/hosts.deny.
#
# short overview about daemons and servers that are built with
# tcp_wrappers support:
#
# package name | daemon path | token
# ----------------------------------------------------------------------------
# ssh, openssh | /usr/sbin/sshd | sshd, sshd-fwd-x11, sshd-fwd-<port>
# quota | /usr/sbin/rpc.rquotad | rquotad
# tftpd | /usr/sbin/in.tftpd | in.tftpd
# portmap | /sbin/portmap | portmap
# The portmapper does not verify against hostnames
# to prevent hangs. It only checks non-local addresses.
#
# (kernel nfs server)
# nfs-utils | /usr/sbin/rpc.mountd | mountd
# nfs-utils | /sbin/rpc.statd | statd
#
# (unfsd, userspace nfs server)
# nfs-server | /usr/sbin/rpc.mountd | rpc.mountd
# nfs-server | /usr/sbin/rpc.ugidd | rpc.ugidd
#
# (printing services)
# lprng | /usr/sbin/lpd | lpd
# cups | /usr/sbin/cupsd | cupsd
# The cupsd server daemon reports to the cups
# error logs, not to the syslog(3) facility.
#
# (Uniterrupted Power Supply Software)
# apcupsd | /sbin/apcupsd | apcupsd
# apcupsd | /sbin/apcnisd | apcnisd
#
# All of the other network servers such as samba, apache or X, have their own
# access control scheme that should be used instead.
#
# In addition to the services above, the services that are started on request
# by inetd or xinetd use tcpd to "wrap" the network connection. tcpd uses
# the last component of the server pathname as a token to match a service in
# /etc/hosts.{allow,deny}. See the file /etc/inetd.conf for the token names.
# The following examples work when uncommented:
#
#
# Example 1: Fire up a mail to the admin if a connection to the printer daemon
# has been made from host foo.bar.com, but simply deny all others:
# lpd : foo.bar.com : spawn /bin/echo "%h printer access" | \
# mail -s "tcp_wrappers on %H" root
#
#
# Example 2: grant access from local net, reject with message from elsewhere.
# in.telnetd : ALL EXCEPT LOCAL : ALLOW
# in.telnetd : ALL : \
# twist /bin/echo -e "\n\raccess from %h declined.\n\rGo away.";sleep 2
#
#
# Example 3: run a different instance of rsyncd if the connection comes
# from network 172.20.0.0/24, but regular for others:
# rsyncd : 172.20.0.0/255.255.255.0 : twist /usr/local/sbin/my_rsyncd-script
# rsyncd : ALL : ALLOW
#



hosts.deny:

# /etc/hosts.deny
# See 'man tcpd' and 'man 5 hosts_access' as well as /etc/hosts.allow
# for a detailed description.

http-rman : ALL EXCEPT LOCAL


Sagt Euch das was? Falls Ihr noch mehr Einstellungen wissen wollt, sagt bitte bescheid.

Danke schonmal für das Gehirnschmalz!

-Markus

High,

also an deiner Basiskonfiguartion liegt das m.E. nicht. jengelh gibt den Hinweis: sieht nach einem NAT- Problem aus

Nukem36

Ich komme einfach nicht weiter. So wie es im Moment aussieht, kann ich aber ohne Probleme auf den Server, wenn ich im Browser bzw. FTP-Client den passive mode deaktiviere. Gibt es irgendeinen Grund, dies nicht zu tun? Macht es von der Sicherheit her einen Unterschied?