vsftp - host lässt Pakete nicht durch

[ThePumpkin]

Moin ladies & gents!
Ich habe ein Problem. Mein Linux host lässt ftp pakete nicht durch - zumindest kann ich mich beim vsftpd nicht anmelden. Der vsftpd ist auf einem virtuellen client installiert.

Ich bekomme solche Meldungen in der /var/log/firewall auf dem host zu lesen


Apr 7 07:06:48 blx2 kernel: [71.180485] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=xx:xx:xx SRC=192.168.10.1 DST=192.168.10.101 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63883 DF PROTO=TCP SPT=55317 DPT=26220 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402-030307)
Apr 7 07:06:51 blx2 kernel: [74.172900] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=xx:xx:xx SRC=192.168.10.1 DST=192.168.10.101 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63884 DF PROTO=TCP SPT=55317 DPT=26220 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402-030307)
Apr 7 07:06:57 blx2 kernel: [80.172883] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=xx:xx:xx SRC=192.168.10.1 DST=192.168.10.101 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63885 DF PROTO=TCP SPT=55317 DPT=26220 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402-030307)


Ich komme bereits vom Host auf den client nicht rauf.

Mit folgender Kette hatte ich versucht den Zugriff zugewärleisten, leider ohne Erfolg obwohl es auf den ersten Blick hin korrekt ist.


iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 11121 -j DNAT --to-destination 192.168.10.101:26220


Habe mit den folgenden Befehl und unten aufgeführten Ergebnis versucht vom Host auf den Client zu verbinden


host ~ # ftp 192.168.10.101 11121
ftp: connect: Connection timed out
ftp>


Konfiguration Host "blx2"
ip 192.168.5.100 Maske 255.255.255.0
Eingangsport ftp 26220 (z.B. aus dem Internet oder LAN)

Konfigration Client "lefty"
ip 192.168.10.101 Maske 255.255.255.0
NAT modus
Eingangsport ftp 11121

Der Client hat Verbindung ins www

"vsftpd.conf" auf dem client (service läuft)


lefty ~ # cat /etc/vsftpd.conf | grep -v "#"
write_enable=YES
dirmessage_enable=YES
nopriv_user=ftpsecure
ftpd_banner=Welcome to lefty´s FTP service.
ls_recurse_enable=YES
deny_email_enable=YES
banned_email_file=/etc/vsftpd.banned_emails
local_enable=YES
local_umask=022
chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list
anonymous_enable=NO
anon_world_readable_only=YES
syslog_enable=YES
log_ftp_protocol=YES
xferlog_enable=YES
vsftpd_log_file=/var/log/vsftpd.log
connect_from_port_20=NO
listen_port=11121
idle_session_timeout=600
data_connection_timeout=120
ascii_upload_enable=YES
pam_service_name=vsftpd
listen=YES
ssl_enable=NO
pasv_min_port=10000
pasv_max_port=12000
chmod_enable=NO
userlist_enable=NO

[DrunkenFreak]

FTP und Firewall ist immer so eine Sache. Ein Port reicht da nicht aus, um eine Verbindung herzustellen. Siehe dazu auch den Wikieintrag über FTP.

Es gibt für Firewall und FTP allerdings zig Treffer bei einer Suchmaschine deiner Wahl.

[Rain_maker]

Ausserdem ist es IMHO eine mässig gute Idee einerseits das Iptables "Einrichtungstool" des Hosts zu verwenden und dann aber von Hand eine weitere Regel mehr oder minder auf gut Glück reinzuballern.

Die SuSEfirewall2 (die hier offensichtlich anhand der geposteten Logeinträge verwendet wird) ermöglicht recht einfach die Einrichtung solcher Umleitungen, also würde ich sie auch dafür verwenden.

Die Einrichtungsdatei /etc/sysconfig/SuSEfirewall2 ist ausführlich dokumentiert und unbedingt einen Blick wert.

[ThePumpkin]

So wie ich das bisher rausgefunden habe, muss ich bei /etc/sysconfig/SuSEfirewall2 solche Eingaben machen


FW_SERVICES_EXT_TCP="ssh", "ftp", "11120 11122"
FW_SERVICES_EXT_UDP="ftp", "11120 11122"


Danach das Netzwerk neu starten. Aber sowas kommt:


lefty:~ # /etc/init.d/network reload
Hint: you may set mandatory devices in /etc/sysconfig/network/config
Setting up network interfaces:
ftp: connect: Invalid argument
ftp: Can't connect or login to host `11120'
/etc/sysconfig/SuSEfirewall2: line 264: 11120 11122: command not found
Setting up service network . . . . . . . . . . done
ftp: connect: Invalid argument
ftp: Can't connect or login to host `11120'
/etc/sysconfig/SuSEfirewall2: line 264: 11120 11122: command not found
SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
SuSEfirewall2: using default zone 'ext' for interface eth0
SuSEfirewall2: Firewall rules successfully set


Also gibt es einen FEhler in Zeile 264. Aber die Beschreibung der Angaben für die entspr. Option - FW_SERVICES_EXT_TCP - erklärt mit das so


## Type: string
#
# Which TCP services _on the firewall_ should be accessible from
# untrusted networks?
#
# Format: space separated list of ports, port ranges or well known
# service names (see /etc/services)
#
# Examples: "ssh", "123 514", "3200:3299", "ftp 22 telnet 512:514"
#
# Note: this setting has precedence over FW_SERVICES_ACCEPT_*

[Rain_maker]

Nein, was da in "" steht ist _jeweils ein_ Beispiel.

Steht ja auch so da, "space separated list" und "Examples".

Ausserdem wolltest Du doch eine Weiterleitung einrichten, also schau Dir besser die Variable FW_REDIRECT an.

[ThePumpkin]

Ach, wie doof von mir. Thx für den Hinweis. Komme trotzdem nicht weiter.


FW_REDIRECT="0/0,192.168.10.101/24,tcp,26220,11120 0/0,192.168.10.101/24,tcp,26221,11121 0/0,192.168.10.101/24,udp,26220,11120 0/0,192.168.10.101/24,udp,26221,11121"


Alles beim alten.


Apr 7 13:22:49 blx2 kernel: [71.180485] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=xx:xx:xx SRC=192.168.10.1 DST=192.168.10.101 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63883 DF PROTO=TCP SPT=55317 DPT=26220 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402-030307)
Apr 7 13:22:52 blx2 kernel: [74.172900] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=xx:xx:xx SRC=192.168.10.1 DST=192.168.10.101 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63884 DF PROTO=TCP SPT=55317 DPT=26220 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402-030307)
Apr 7 13:22:58 blx2 kernel: [80.172883] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=xx:xx:xx SRC=192.168.10.1 DST=192.168.10.101 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63885 DF PROTO=TCP SPT=55317 DPT=26220 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402-030307)


Was mir aber auffällt ist der "SPT" - also "source port" wohl. Ich versuche mit "ftp 192.168.10.100 26220" rein zu kommen. Aber hier ist der "SPT" gleich "55317".

[Rain_maker]

Also zuerst mal vorweg.

1) Ich sage nicht, daß das, was Du da vorhast prinzipiell nicht gehen würde, es fragt sich nur, ob Du es Dir nicht unnötig schwer machst.

2) Der Source Port ist irrelevant, den wählt der Client mehr oder minder zufällig, wichtig sind die Zielports (oder auch "--sport ist Mord" :-)).

Lies Dir mal das hier durch

http://de.wikipedia.org/wiki/File_Transfer_Protocol

vor allem den Abschnitt zu aktivem und passivem FTP.

Laut Konfiguration aus Deinem ersten Post verwendest Du passives FTP, was prinzipiell eine gute Idee ist, nur steht dann -soweit ich mich nicht ganz schwer irre- fest, daß Du Dir für diese Ports solche "Umlenkungen" der Marke "Client kommt am Host auf Port XYZ an und ich leite das auf Port ABC im Gast weiter" nicht leisten kannst.

Ich persönlich würde das so machen.

a) Gastsystem "normal" konfigurieren und einen nicht zu großen Portrange für passives FTP wählen (20-30 Ports sollten eigentlich reichen).

b) in der NAT-Implementierung der Virtualisierungssoftware eine entsprechende Portweiterleitung auf die selben (sic!) Ports des Host unter einer von aussen erreichbaren Adresse einrichten (am einfachsten auf 0.0.0.0 oder die 192.168er Adresse des Hosts, für Erreichbarkeit von aussen wirst Du dann eh noch ein Portforwarding in Deinem Router einrichten müssen, aber darüber bist Du Dir wahrscheinlich eh schon im Klare.)

c) Diese Ports in der Firewall des Hostsystems freigeben und sich die Umbiegerei ersparen, das bringt in diesem Fall keine weitere Sicherheit sondern nur Ärger.

Wenn überhaupt, dann würde ich bei FTP nur den Control Port umleiten, alles Andere schreit nach Problemen.

Greetz,

RM

[ThePumpkin]

hi, danke. Bin schon weiter. Ich musste einfach die alten Regeln rauslöschen, die haben iptables vermüllt.

Ich komme jetzt insofern weiter, daß ich mich tatsächlich verbinden kann (mit filezilla von einem windows client und vom host auch). Aber es wird nicht alles gelesen


Status: Verbinde mit xxx.xxx.xxx.xxx:11121...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Antwort: 220 Welcome to lefty´s FTP service.
Befehl: USER ftp02933
Antwort: 331 Please specify the password.
Befehl: PASS *********
Antwort: 230 Login successful.
Befehl: OPTS UTF8 ON
Antwort: 200 Always in UTF8 mode.
Status: Verbunden
Status: Empfange Verzeichnisinhalt...
Befehl: PWD
Antwort: 257 "/home/pumpkin/ftpdaten"
Befehl: TYPE I
Antwort: 200 Switching to Binary mode.
Befehl: PASV
Antwort: 227 Entering Passive Mode (192,168,10,101,47,52).
Status: Vom Server gesendete Adresse für den Passiv-Modus ist nicht routingfähig. Benutze stattdessen die Serveradresse.
Befehl: LIST


Hier habe ich versucht mit einem windows 7 client durch das Internet zum Host und von dort zum Gastsystem (wo vsftpd ist) durchzukommen.

Mit einem anderen ftp tool - total commander - kommt die Meldung "PORT Kommando fehlgeschlagen!"

Die iptables Regel auf dem Hostsystem ist

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 11121 -j DNAT --to-destination 192.168.10.101:21

Die vsftpd Einstellungen habe ich auf deinen Rat hin verändert


write_enable=YES
dirmessage_enable=YES
nopriv_user=ftpsecure
ftpd_banner=Welcome to lefty´s FTP service.
ls_recurse_enable=YES
deny_email_enable=YES
banned_email_file=/etc/vsftpd.banned_emails
local_enable=YES
local_umask=022
chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list
anonymous_enable=NO
anon_world_readable_only=YES
syslog_enable=YES
log_ftp_protocol=YES
xferlog_enable=YES
vsftpd_log_file=/var/log/vsftpd.log
connect_from_port_20=YES
listen_port=21
idle_session_timeout=600
data_connection_timeout=120
ascii_upload_enable=YES
pam_service_name=vsftpd
listen=YES
ssl_enable=NO
pasv_min_port=11115
pasv_max_port=11125
chmod_enable=NO
userlist_enable=NO


Verzeichnis /home/ftpdata ist mit chmod 765 und chown ftp02933:ftp-users geöffnet worden, der user ftp02933 ist natürlich Mitglied dieser Gruppe.

Einige Testdateien habe ich in dem ftp Verzeichnis angelegt, aber diese werden beim verbinden mit dem ftp tool - egal welches - nicht eingelesen. Das hängt klar mit den Fehlermeldungen zusammen.

[ThePumpkin]

Auf den suse gastsystem kommt folgendes aus den Logs


Apr 10 12:49:46 lefty kernel: [71412.156293] SFW2-INext-ACC-TCP IN=eth0 OUT= MAC=xx:xx:xx:xx SRC=xx:xx:xx:xx DST=192.168.10.101 LEN=52 TOS=0x00 PREC=0x00 TTL=117 ID=29165 DF PROTO=TCP SPT=12557 DPT=21 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (0204-12202)
Apr 10 12:49:46 lefty kernel: [71412.212066] lo: Disabled Privacy Extensions
Apr 10 12:49:47 lefty vsftpd[1]: [ftp02933] OK LOGIN: Client "xx:xx:xx:xx"
Apr 10 12:49:47 lefty kernel: [71412.449517] lo: Disabled Privacy Extensions
Apr 10 12:49:47 lefty vsftpd[1]: [ftp02933] FTP response: Client "xx:xx:xx:xx", "230 Login successful."
Apr 10 12:49:47 lefty vsftpd[1]: [ftp02933] FTP command: Client "xx:xx:xx:xx", "OPTS UTF8 ON"
Apr 10 12:49:47 lefty vsftpd[1]: [ftp02933] FTP response: Client "xx:xx:xx:xx", "200 Always in UTF8 mode."
Apr 10 12:49:47 lefty vsftpd[1]: [ftp02933] FTP command: Client "xx:xx:xx:xx", "PWD"
Apr 10 12:49:47 lefty vsftpd[1]: [ftp02933] FTP response: Client "xx:xx:xx:xx", "257 "/home/pumpkin/ftpdaten""
Apr 10 12:49:47 lefty vsftpd[1]: [ftp02933] FTP command: Client "xx:xx:xx:xx", "TYPE I"
Apr 10 12:49:47 lefty vsftpd[1]: [ftp02933] FTP response: Client "xx:xx:xx:xx", "200 Switching to Binary mode."
Apr 10 12:49:47 lefty vsftpd[1]: [ftp02933] FTP command: Client "xx:xx:xx:xx", "PASV"
Apr 10 12:49:47 lefty vsftpd[1]: [ftp02933] FTP response: Client "xx:xx:xx:xx", "227 Entering Passive Mode (192,168,10,101,47,46)."
Apr 10 12:49:47 lefty vsftpd[1]: [ftp02933] FTP command: Client "xx:xx:xx:xx", "LIST"


Was mir auffällt ist
"227 Entering Passive Mode (192,168,10,101,47,46)." wobei es um
",47,46" geht - was haben diese Zahlen zu bedeuten? Sind das zusätzlich benötigte Ports? Normalerweise (bei jeden mal) ändert sich die zweite Zahl. Manchmal steht das "46", aber auch "51" oder "57","42" usw.

[Rain_maker]

Ich kann dazu nur eines sagen.

Ich habe das Ganze jetzt mal aus Jux und Dollerei genau so eingerichtet wie weiter oben unter "Also ich würde das so machen" beschrieben und es hat einwandfrei im LAN funktioniert.

Das Einzige, was noch fehlen würde wären nun die Portweiterleitungen im Router um von aussen dran zu kommen, was ich mir aber aus offensichtlichen Gründen erspart habe.

Gast:

openSUSE 11.4, VirtualBox im NAT mode

vsftpd:

- passive Ports von 30000-30005 (zum Testen reicht das dicke), Portweiterleitung auf den Host über VirtualBox mit _exakt_ dem selben Zielport im Host

- control Port 21, Portweiterleitung der VirtualBox auf einen non-privileged Port (2121, aber jeder über 1024 wäre OK)

- SuSEfirewall2 im Gast, obere Ports geöffnet (wobei man im Gast die Firewall auch einfach deaktivieren kann)

Host: openSUSE 11.4

- Port 21 eingehend auf Port 2121 "umgebogen" (mit SuSEfirewall und FW_REDIRECT, siehe weiter oben)

- Ports 30000-30005 in der SuSEfirewall2 freigegeben

Und fertig, ging ehrlicherweise keine 5 Minuten.

Greetz,

RM

[ThePumpkin]

Mein Host gibt nichts an Fehlermeldungen aus, nur das Gastsystem. Das müsste bedeuten, dass die Weiterleitungen und Umleitungen dort richtig sind. Da der HOst aber kein suse sondern debian ist, gibt es auch keine SuSEfirewall2 darauf. Alles deutet auf das Gastsystem hin.

Hier der Auszug aus der jetzigen /etc/sysconfig/SuSEfirewall2 Datei auf dem Gastsystem.


cat /etc/sysconfig/SuSEfirewall2 | grep -v "#"
FW_DEV_EXT=""
FW_DEV_INT=""
FW_DEV_DMZ=""
FW_ROUTE="no"
FW_MASQUERADE="no"
FW_MASQ_DEV=""
FW_MASQ_NETS=""
FW_NOMASQ_NETS=""
FW_PROTECT_FROM_INT="no"
FW_SERVICES_EXT_TCP="ssh ftp 11115:11125"
FW_SERVICES_EXT_UDP=""
FW_SERVICES_EXT_IP=""
FW_SERVICES_EXT_RPC=""
FW_CONFIGURATIONS_EXT=""
FW_SERVICES_DMZ_TCP=""
FW_SERVICES_DMZ_UDP=""
FW_SERVICES_DMZ_IP=""
FW_SERVICES_DMZ_RPC=""
FW_CONFIGURATIONS_DMZ=""
FW_SERVICES_INT_TCP=""
FW_SERVICES_INT_UDP=""
FW_SERVICES_INT_IP=""
FW_SERVICES_INT_RPC=""
FW_CONFIGURATIONS_INT=""
FW_SERVICES_DROP_EXT=""
FW_SERVICES_DROP_DMZ=""
FW_SERVICES_DROP_INT=""
FW_SERVICES_REJECT_EXT=""
FW_SERVICES_REJECT_DMZ=""
FW_SERVICES_REJECT_INT=""
FW_SERVICES_ACCEPT_EXT=""
FW_SERVICES_ACCEPT_DMZ=""
FW_SERVICES_ACCEPT_INT=""
FW_SERVICES_ACCEPT_RELATED_EXT=""
FW_SERVICES_ACCEPT_RELATED_DMZ=""
FW_SERVICES_ACCEPT_RELATED_INT=""
FW_TRUSTED_NETS=""
FW_FORWARD=""
FW_FORWARD_REJECT=""
FW_FORWARD_DROP=""
FW_FORWARD_MASQ=""
FW_REDIRECT=""
#"0/0,192.168.10.101,tcp,21,11121 0/0,192.168.10.101,tcp,20,11120"
FW_LOG_DROP_CRIT="yes"
FW_LOG_DROP_ALL="yes"
FW_LOG_ACCEPT_CRIT="yes"
FW_LOG_ACCEPT_ALL="no"
FW_LOG_LIMIT=""
FW_LOG=""
FW_KERNEL_SECURITY=""
FW_STOP_KEEP_ROUTING_STATE=""
FW_ALLOW_PING_FW=""
FW_ALLOW_PING_DMZ=""
FW_ALLOW_PING_EXT=""
FW_ALLOW_FW_SOURCEQUENCH=""
FW_ALLOW_FW_BROADCAST_EXT="no"
FW_ALLOW_FW_BROADCAST_INT="no"
FW_ALLOW_FW_BROADCAST_DMZ="no"
FW_IGNORE_FW_BROADCAST_EXT="yes"
FW_IGNORE_FW_BROADCAST_INT="no"
FW_IGNORE_FW_BROADCAST_DMZ="no"
FW_ALLOW_CLASS_ROUTING=""
FW_CUSTOMRULES=""
FW_REJECT=""
FW_REJECT_INT=""
FW_HTB_TUNE_DEV=""
FW_IPv6=""
FW_IPv6_REJECT_OUTGOING=""
FW_IPSEC_TRUST="no"
FW_ZONES=""
FW_ZONE_DEFAULT=""
FW_USE_IPTABLES_BATCH=""
FW_LOAD_MODULES="nf_conntrack_netbios_ns"
FW_FORWARD_ALWAYS_INOUT_DEV=""
FW_FORWARD_ALLOW_BRIDGING=""
FW_WRITE_STATUS=""
FW_RUNTIME_OVERRIDE=""
FW_LO_NOTRACK=""
FW_BOOT_FULL_INIT=""


Eine Redirect Zeile habe ich dort aufgelistet, die ist deaktiviert denn die Regeln sind wohl eher was für den Host. Ich glaube du hattest mich falsch verstanden vom Anfang an.

Ich habe auf einem Debian eine Virtuelle Maschine und darin SuSE 11.4 laufen.

[Rain_maker]

Dann zitiere ich mich mal selbst:
- SuSEfirewall2 im Gast, obere Ports geöffnet (wobei man im Gast die Firewall auch einfach deaktivieren kann)
es sei denn, Du hast einen wirklich guten Grund, wieso die in einem "geNATteten" Gast laufen soll.

Wenn es dann immer noch nicht funktioniert, solltest Du Deine Theorie "Firewall im Gast ist schuld" überdenken.

[Rain_maker]

Hm, ich bin da gerade über etwas gestolpert, das könnte ganz schön dumm gelaufen sein.

Bei meinem Test vorhin, der auf die Schnelle passieren musste, war ich (von aussen) per ssh auf dem Host eingeloggt.

Folgendes hatte ich gemacht.

1) Bei nicht laufender VM (Name = openSUSE-11.4-32) das Portforwarding für einen NAT-Adapter unter VirtualBox eingerichtet, Port 2121 sollte der Control Port sein, die Ports 30000-30005 die Ports für passives FTP


VBoxManage modifyvm "openSUSE-11.4-32" --natpf1 "vsftpdcontrol,tcp,,2121,,21"

for i in {30000..30005} ; do VBoxManage modifyvm "openSUSE-11.4-32" --natpf1 "vsftpdpassive$i,tcp,,$i,,$i" ; done2) VM gestartet (Headless) und nachgesehen, ob die Ports im Host offen sind.


netstat -tupeln|grep -E '3000|21'

tcp 0 0 0.0.0.0:30000 0.0.0.0:* LISTEN 1000 58146 -
tcp 0 0 0.0.0.0:30001 0.0.0.0:* LISTEN 1000 58145 -
tcp 0 0 0.0.0.0:30002 0.0.0.0:* LISTEN 1000 58144 -
tcp 0 0 0.0.0.0:30003 0.0.0.0:* LISTEN 1000 58143 -
tcp 0 0 0.0.0.0:2121 0.0.0.0:* LISTEN 1000 58147 -
tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN 1000 58142 -
tcp 0 0 0.0.0.0:30005 0.0.0.0:* LISTEN 1000 58141 -

3) Vom Host per ssh auf den Gast, vsftpd passend zu den oben freigeschalteten Ports eingerichtet, eine kleine Testdatei im FTP-Verzeichnis (default = /srv/ftp) abgelegt, vsftpd mit "rcvsftpd start" gestartet und wieder raus aus dem Gast.

4) Auf dem Host lftp (übrigens eine Empfehlung für die Nachwelt, nicht nur als ftp-client) gestartet und Folgendes gemacht


lftp
lftp :~> connect 127.0.0.1:2121
lftp 127.0.0.1:~>ls -l
-rw-r--r-- 1 0 0 19 Apr 10 16:18 It_works.txt
lftp 127.0.0.1:/> cat It_works.txt
Na also, geht doch
19 Bytes übertragenDas Portforwarding von VirtualBox funktioniert also anscheinend, die 127.0.0.1 hatte ich deshalb genommen, weil wenn ein Dienst auf "0.0.0.0" (siehe oben) lauscht, dann ist ja normalerweise jede Adresse "gut genug".

So, und jetzt kommt das Ding.

Im Host gibt es auch das Interface eth0:


2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 10.42.23.1/24 brd 10.42.23.255 scope global eth0

Naja, wie gesagt, wenn ein Dienst auf 0.0.0.0 lauscht, dann isses ja wurscht, über welche lokale Adresse man sich verbindet, oder?


connect ftp://10.42.23.1:2121
lftp 10.42.23.1:~> ls -l
»ls -l« bei 0 [Stelle Datenverbindung her...]und das wars, kein Listing.

Für mich sieht das weder nach einem Problem im Host noch nach einem im Gast aus, sondern eher nach einem Bug in der NAT-Implementierung von VirtualBox, wobei andere Protokolle (ssh, http) mit der selben Methode problemlos funktionieren.

Probier das doch auch mal genau so, also auf dem Host über 127.0.0.1 auf den FTP-Server im Gast zuzugreifen.

Greetz,

RM

[ThePumpkin]

hi,
bei mir kommt das gleiche auf dem Host, wenn ich mit lsftp zugreifen will


debian ~ # lftp 127.0.0.1:11121
lftp 127.0.0.1:~> ls -l
`ls -l' at 0 [Delaying before reconnect: 27]


Mit "ftp" (debian Host) kommt sowas


debian ~ # ftp 127.0.0.1 11121
ftp: connect: Connection refused


Auf dem Host (debian) kommt netstat Ausgabe


debian~ # netstat -tupeln|grep -E '11121|21'
udp6 0 0 fe80::21d:92ff:xxx:xxx :::* 0 5465 1538/ntpd


und auf dem Gastsystem (SuSE) sowas


suse~ # netstat -tupeln|grep -E '11121|21'
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 0 23413 9988/vsftpd


Habe auf Gast die SuSEfirewall2 ausgeschaltet:


/etc/init.d/SuSEfirewall2_setup stop


Doch keine Verbesserung erzielt.

[Rain_maker]

Habe auf Gast die SuSEfirewall2 ausgeschaltet:


/etc/init.d/SuSEfirewall2_setup stop


Doch keine Verbesserung erzielt.

Klar, liegt ja auch nicht am Gast, wobei, wenn das hier wirklich stimmt


Auf dem Host (debian) kommt netstat Ausgabe


debian~ # netstat -tupeln|grep -E '11121|21'
udp6 0 0 fe80::21d:92ff:xxx:xxx :::* 0 5465 1538/ntpd


dann brauchst Du Dich nicht zu wundern, warum da nichts geht selbst wenn es möglicherweise das oben beschriebene Problem mit dem Portforwarding bei VirtualBox geben sollte.

Nach welchen Ports Du bei netstat greppen solltest, musst Du natürlich selbst wissen, wenn 11121 oder 21 bei den von Dir eingerichteten nicht dabei sind, dann war der grep-Befehl sinnlos.

[ThePumpkin]

Na, ich habe auf dem Host den Port 11121 auf 21 umgeleitet

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 11121 -j DNAT --to-destination 192.168.10.101:21

Vielleicht mache ich ja einen Denkfehler - muss ich den Port 11121 noch extra öffnen? Iptables ist nicht so mein Ding, da hackt es gewaltig bei mir. :rolleyes:

[Rain_maker]

Vielleicht mache ich ja einen Denkfehler - muss ich den Port 11121 noch extra öffnen? Iptables ist nicht so mein Ding, da hackt es gewaltig bei mir. :rolleyes:

Deine "Iptables-Umbiegeregeln" interessieren beim Zugriff über localhost nicht und bevor man da irgendwelches VooDoo veranstaltet, sollte man zuerst sicherstellen, daß man an den Server überhaupt rankommt.

Hast Du überhaupt ein Portforwarding Gast<->Host z.B. mit VBoxManage eingerichtet?

[ThePumpkin]

Pfff - ich ging davon aus, daß das nicht nötig wäre da ssh usw. funktioniert. Allerdings verwende ich vmware 8 - das ist etwas anders als virtualbox. Hier gibt es bestimmt dann auch noch ein externes tool, welches ich noch nicht gefunden habe - richtig?

Habe mal auf dem Host nach "LISTEN" gegrept.


debian ~ # netstat -an | grep "LISTEN"
tcp 0 0 127.0.0.1:8307 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:902 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6001 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 :::5901 :::* LISTEN

[Rain_maker]

Bei vmware bin ich raus.

Notiz an mich selbst:

Glaube nie wieder, Du müsstest nicht jeden Kleinkram noch einmal extra nachfragen, nur weil Du es an anderer Stelle

http://www.linuxforen.de/forums/showthread.php?t=273155


... auf meinem suse Testserver, den ich auf virtualbox installiert habe ...

meinst schon gelesen zu haben.

*Grml*

//Edit:

Falls ein VirtualBox-Benutzer mit Interesse für dieses seltsame Problem, welches ich in Posting Nr. 13 beschrieben habe, über diesen Thread stolpern sollte, bitte versuchen zu reproduzieren. Meine Version von VBox war zum Zeitpunkt des Tests 4.1.12.

[ThePumpkin]

Das liegt daran, daß ich virtualbox wieder rausgenommen hatte, weil es nur Ärger damit gab, und auf vmware umgestiegen war. Sry, hätte es hier erwähnen sollen. Hab aber nicht damit gerechnet, daß jemand noch in anderen Threads nach Fakten sucht. Ich habe jetzt vmware 8.0 installiert.

Allerdings ist der Fehler - wenn auch mit anderer Virtualisierungssoftware - doch reproduziert oder?