iptables Port forwarding will nicht funktionieren

[DerH0ns]

Hallo,
ich habe mir eine VM mit Qemu erstellt, diese ist über in Tap-Interface in das Netzwerk eingebunden. Nun habe ich versucht, da ich keine 2. haben möchte per iptables einen Port zur VM umzuleiten.
Dies funktioniert aber nicht. Hier mein Setup:
Iptables

Code: Alles auswählen

iptables -A INPUT -j ACCEPT
iptables -A FORWARD -j ACCEPT
iptables -A OUTPUT -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -d 192.168.178.29 --dport 6422 -j DNAT --to-destination 10.0.2.101:22
iptables -t nat -A POSTROUTING -o wlan0 -d 10.0.2.101 -j SNAT --to-source 192.168.178.29

Ifconfig:

Code: Alles auswählen

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX packets:4954 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4954 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX-Bytes:919200 (919.2 KB)  TX-Bytes:919200 (919.2 KB)

tap0      Link encap:Ethernet  Hardware Adresse 4a:75:26:07:2a:43  
          inet Adresse:10.0.2.100  Bcast:10.255.255.255  Maske:255.0.0.0
          inet6-Adresse: fe80::4875:26ff:fe07:2a43/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:210 errors:0 dropped:0 overruns:0 frame:0
          TX packets:330 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:500 
          RX-Bytes:27865 (27.8 KB)  TX-Bytes:38936 (38.9 KB)

wlan0     Link encap:Ethernet  Hardware Adresse bc:05:43:09:5f:25  
          inet Adresse:192.168.178.29  Bcast:192.168.178.255  Maske:255.255.255.0
          inet6-Adresse: fe80::be05:43ff:fe09:5f25/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:18590 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18278 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX-Bytes:11743144 (11.7 MB)  TX-Bytes:4332587 (4.3 MB)

Forwarding ist an:

Code: Alles auswählen

cat /proc/sys/net/ipv4/ip_forward
1

... aber trozdem komme ich über den Port 6422 nicht an die VM. Ich habe schon viel gegoogelt, aber auch nur das gefunden was nicht funktioniert. Hat jemand eine Idee wo mein Fehler liegen könnte?

[syssi]

Du koenntest dem wlan0-Device auch eine weitere IP-Adresse geben:

Code: Alles auswählen

ifconfig wlan0:0 192.168.178.30

Ich habe ein aehnliches Setup in Betrieb. Meine iptables-Zeilen sehen so aus:

Code: Alles auswählen

/sbin/iptables -t nat -A PREROUTING -d 192.168.178.29 -j DNAT --to 10.0.2.101
/sbin/iptables -t nat -A POSTROUTING -s 10.0.2.101 -o wlan0 -j SNAT --to-source 192.168.178.29

[DerH0ns]

Eine 2. IP möchte ich nicht, da ich das ganze wenn es dann läuft auf meinem Server haben möchte.
Wenn ich die Regeln von dir um eine Portbeschränkung erweitere funktioniert es nicht mehr. Muss doch aber möglich sein, die Regeln auf auf nur einen Port zu beschränken.

[Cae]

Zwei Ideen: In FORWARD koennte sich vor'm -A noch ein DROP befinden. Die Anfrage koennte ausserdem aus einem weiteren Netz stammen, wohin der Host keine Rueckroute hat. Poste dazu

Code: Alles auswählen

# iptables-save
$ ip route

Gruss Cae

[DerH0ns]

Iptables:

Code: Alles auswählen

# Generated by iptables-save v1.4.12 on Sun May  5 11:25:27 2013
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 192.168.178.29/32 -p tcp -m tcp --dport 6422 -j DNAT --to-destination 10.0.2.101:22
-A POSTROUTING -d 10.0.2.101/32 -o wlan0 -j SNAT --to-source 192.168.178.29
COMMIT
# Completed on Sun May  5 11:25:27 2013
# Generated by iptables-save v1.4.12 on Sun May  5 11:25:27 2013
*mangle
:PREROUTING ACCEPT [396:61310]
:INPUT ACCEPT [396:61310]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [401:60505]
:POSTROUTING ACCEPT [401:60505]
COMMIT
# Completed on Sun May  5 11:25:27 2013
# Generated by iptables-save v1.4.12 on Sun May  5 11:25:27 2013
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -j ACCEPT
-A FORWARD -j ACCEPT
-A OUTPUT -j ACCEPT
COMMIT
# Completed on Sun May  5 11:25:27 2013

Ip route:

Code: Alles auswählen

default via 192.168.178.1 dev wlan0 
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.29

[syssi]

Versuchs mal so:

Code: Alles auswählen

/sbin/iptables -t nat -A PREROUTING -d 192.168.178.29 -p tcp --dport 6422 -j DNAT --to 10.0.2.101:22
/sbin/iptables -t nat -A POSTROUTING -s 10.0.2.101 -o wlan0 -j MASQUERADE

SNAT ist AFAIK der falsche Ansatz, wenn du nur eine einzelne IP zur Verfuegung hast.

[r900]

SNAT ist AFAIK der falsche Ansatz, wenn du nur eine einzelne IP zur Verfuegung hast.

Kannst du das etwas ausführlicher begründen? Ich denke SNAT sollte funktionieren.

Allerdings ist die Regel meiner Meinung nach falsch formuliert. Sie soll alle Pakete erfassen die von 10.0.2.101/32 kommen. Also nicht

Code: Alles auswählen

-A POSTROUTING -d 10.0.2.101/32 -o wlan0 -j SNAT --to-source 192.168.178.29

sondern

Code: Alles auswählen

-A POSTROUTING -s 10.0.2.101/32 -o wlan0 -j SNAT --to-source 192.168.178.29

Nachtrag:
Außerdem sehe ich keine route zu 10.0.2.101/32.

Ip route:

Code: Alles auswählen

default via 192.168.178.1 dev wlan0
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.29

[syssi]

SNAT ist AFAIK der falsche Ansatz, wenn du nur eine einzelne IP zur Verfuegung hast.

Kannst du das etwas ausführlicher begründen? Ich denke SNAT sollte funktionieren.

Ich versuchs mal: Die DNAT-Regel ist nichts weiter als eine Port-Weiterleitung. Man kann sich also vorstellen, dass das Host-System den Router darstellt mit eine WAN-IP. Ein spezieller Port soll an den Gast weitergereicht werden. Die SNAT-Regel soll normalerweise bewirken, dass die Quell-IP des ausgehenden Traffics auf eine oeffentlich erreichbare IP umgeschrieben wird. Meine Annahme war, dass man dem Router dafuer eine weitere WAN-IP geben muss, so dass sich die beiden Systeme nicht ins Gehege kommen. Ich liege aber vermutlich falsch? http://unix.stackexchange.com/questions ... masquerade

[r900]

Meine Annahme war, dass man dem Router dafuer eine weitere WAN-IP geben muss, so dass sich die beiden Systeme nicht ins Gehege kommen. Ich liege aber vermutlich falsch?

Wie so oft hilft die man-page, hatte nur schon wieder vergessen was ich dort mal gelesen hatte. Eine weitere (zusätzliche) Adresse braucht man nicht. Wenn man eine feste IP-Adresse hat ist SNAT der richtige Weg. Bei dynamischer Adresse muss man auf MASQUERADE ausweichen:

MASQUERADE
This target is only valid in the nat table, in the POSTROUTING chain. It should only be used with dynamically assigned IP (dialup) connections: if you have a static IP address, you should use the SNAT target. Masquerading is equivalent to specifying a mapping to the IP address of the interface the packet is going out, but also has the effect that connections are forgotten when the interface goes down. This is the correct behavior when the next dialup is unlikely to have the same interface address (and hence any established connections are lost anyway).

[syssi]

Lesen bildet. Ich ziehe meine Behauptung zurueck!

[DerH0ns]

Code: Alles auswählen

-A POSTROUTING -s 10.0.2.101/32 -o wlan0 -j SNAT --to-source 192.168.178.29

Hat nichts gebracht, habe ich vorher auch schonmal probiert.

Nachtrag:
Außerdem sehe ich keine route zu 10.0.2.101/32.

Könnte das nicht das Problem sein, wie kann ich eine Route hinzufügen?

[wanne]

Das sollte das reichen:

Code: Alles auswählen

iptables -t nat -A PREROUTING -p tcp -d 192.168.178.29 --dport 6422 -j DNAT --to-destination 10.0.2.101:22

DNAT merkt sich woher was kam. und letet wieder in die andere Richtung um.
Schmeiß mal den weg:

Code: Alles auswählen

iptables -t nat -A POSTROUTING -o wlan0 -d 10.0.2.101 -j SNAT --to-source 192.168.178.29

Route muss natürlich hin

Code: Alles auswählen

ip route add 10.0.0.0/8 dev tap0

Wie hst du denn die IP gesetzt bekommen ohne das er dir automatisch eine route hinzufügt?

PS: habt ihr gesehen wie modern ich bin? Ich benutze jetzt IP und nicht mehr route XD.

[DerH0ns]

Wie gehabt, es funktioniert nicht:

Code: Alles auswählen

marvin@marvin:~$ ssh root@192.168.178.29 -p 6422
ssh: connect to host 192.168.178.29 port 6422: Connection refused


marvin@marvin:~$ ssh root@10.0.2.101
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
35:dc:34:03:a6:5e:70:ea:b6:49:d9:40:58:f6:12:fa.
Please contact your system administrator.
Add correct host key in /home/marvin/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/marvin/.ssh/known_hosts:26
  remove with: ssh-keygen -f "/home/marvin/.ssh/known_hosts" -R 10.0.2.101
RSA host key for 10.0.2.101 has changed and you have requested strict checking.
Host key verification failed.

Route stimmt auch:

Code: Alles auswählen

default via 192.168.178.1 dev wlan0 
10.0.0.0/8 dev tap0  proto kernel  scope link  src 10.0.2.100 
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.29 

Ifconfig:

Code: Alles auswählen

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX packets:14108 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14108 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX-Bytes:2215599 (2.2 MB)  TX-Bytes:2215599 (2.2 MB)

tap0      Link encap:Ethernet  Hardware Adresse ee:61:36:ae:d0:5b  
          inet Adresse:10.0.2.100  Bcast:10.255.255.255  Maske:255.0.0.0
          inet6-Adresse: fe80::ec61:36ff:feae:d05b/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:36 errors:0 dropped:0 overruns:0 frame:0
          TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:500 
          RX-Bytes:7539 (7.5 KB)  TX-Bytes:18269 (18.2 KB)

wlan0     Link encap:Ethernet  Hardware Adresse bc:05:43:09:5f:25  
          inet Adresse:192.168.178.29  Bcast:192.168.178.255  Maske:255.255.255.0
          inet6-Adresse: fe80::be05:43ff:fe09:5f25/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:1175622 errors:0 dropped:0 overruns:0 frame:0
          TX packets:896583 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX-Bytes:1300745405 (1.3 GB)  TX-Bytes:99837329 (99.8 MB)

[wanne]

Hast du die 2. Regel rausgeworfen?

[DerH0ns]

Ja hab ich.

[r900]

Was route angeht, schau mal hier (Punkt 2): http://floppsie.comp.glam.ac.uk/Glamorg ... ss/11.html
Man beachte: "you will have to have configured the server xxx in the same way"

[DerH0ns]

Vom Host komme ich auch so auf die VM aber nur über die lokale IP. Mein Problem besteht ja nicht darin zu Pingen sondern einen Port von der Öffentlichen IP auf die VM zu leiten.
So wie die die Anleitung die du gepostet hast verstanden habe bekomme ich dann eine 2., öffentliche IP für die VM was ich aber nicht will.

[debnuxer]

Ist hier forwarding auch an?
/proc/sys/net/ipv4/conf/eth0/forwarding

Das eth0 Interface ggf. ersetzen.

[DerH0ns]

Ja ist aktiv.

Code: Alles auswählen

cat /proc/sys/net/ipv4/conf/wlan0/forwarding
1

sowie:

Code: Alles auswählen

cat /proc/sys/net/ipv4/ip_forward 
1

[r900]

So, da mich das ganze auch selbst interessiert hat habe ich jetzt mal ein bisschen probiert. Mein Host: eth0 mit IP 192.168.0.101
Also zuerst erstelle ich das tap-device, gebe dem die IP 10.10.0.1 und aktiviere ip-forwarding:
# tunctl
Set 'tap0' persistent and owned by uid 0
# ifconfig tap0 10.10.0.1 up
# echo 1 > /proc/sys/net/ipv4/ip_forward
# ip route
default via 192.168.0.1 dev eth0
10.0.0.0/8 dev tap0 proto kernel scope link src 10.10.0.1
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.101
(Anm.: den route-Eintrag hat ifconfig automatisch erstellt)

Ab hier bis auf weiteres in der VM (Virtualbox, tap-device als Netzwerkbrücke).
Dort sehe ich tap0 des hosts als eth0 und konfiguriere es in /etc/network/interfaces:

Code: Alles auswählen

auto eth0
iface eth0 inet static
   address 10.10.0.2
   netmask 255.0.0.0
   gateway 10.10.0.1
   dns-nameservers 8.8.8.8

(Anm.: 8.8.8.8 ist ein DNS server von Google wenn ich nicht irre)

Nun das interface aktivieren und sehen ob der Host erreichbar ist:
# ifup eth0
# ping 10.10.0.1
64 bytes from 10.10.0.1: icmp_req=1 ttl=64 time=0.221 ms
# ping 8.8.8.8
-> 100% packet loss

Wir sehen also: Host ist erreichbar, von einer externen Adresse kommt allerdings nicht zurück. Deshalb brauchen wir iptables. Auf dem Host:
# iptables -t nat -A POSTROUTING -o eth0 -s 10.10.0.2 -j SNAT --to 192.168.0.101
(Anm.: Dadurch wird in allen Paketen die von unserer VM kommen und über eth0 des Hosts heraus gehen der Absender von 10.10.0.2 auf 192.168.0.101 geändert. Ohne das sind keine ausgehenden Verbindungen [von der VM initiiert] möglich.)

Jetzt wieder in der VM:
# ping 8.8.8.8
64 bytes from 8.8.8.8: icmp_req=1 ttl=50 time=32.8 ms
# ping http://www.google.com
PING http://www.google.com (173.194.32.18) 56(84) bytes of data.
64 bytes from arn06s01-in-f18.1e100.net (173.194.32.18): icmp_req=1 ttl=57 time=8.53 ms
-> ausgehende Verbindungen und Namensauflösung funktionieren

So und jetzt noch einen port vom Host weiterleiten:
# iptables -t nat -A PREROUTING -d 192.168.0.101 -p tcp --dport 10000 -j DNAT --to 10.10.0.2:22
(Anm.: Der Unterschied zwischen "-d" (destination) und "-s" (source) sollte jetzt hoffentlich auch klar sein)

Damit kann ich mit einem Rechner aus dem 192.168.0.1/24 Subnetz auf den ssh-server der VM zugreifen. Vom Host selbst funktioniert
$ ssh user@192.168.0.101 -p 10000
allerdings nicht. So wie ich es verstehe durchlaufen Pakete vom Host die auf die Host-eigene IP-Adresse gehen nicht das übliche pre- und postrouting. Ist aber auch nicht weiter tragisch, denn vom Host selbst kann man ja mit 10.10.0.2 direkt kommunizieren.

[DerH0ns]

Danke! Nun funktioniert es endlich, Fehler waren eigtl. nur das ich kein Gateway konfiguriert hatte und der Zugriff vom Host aus nicht funktioniert(weswegen ich dachte es funktioniert gar nicht).

[DerH0ns]

Habe jetzt doch noch eine Frage, ich habe nun eine VM die Funktioniert, nun wollte ich eine 2. erstellen allerdings kann diese nicht auf das Netzwerk zugreifen.
Gestartet wird sie über:

Code: Alles auswählen

qemu-system-x86_64 -hda disk.1.img -cdrom debian-6.0.3-amd64-CD-1.iso -boot c -m 3000 -smp 2 -net nic,vlan=0 -net tap,vlan=0,ifname=tap1,script=/root/qemu/ifup2,downscript=/root/qemu/ifdown

Die Funktionierende:

Code: Alles auswählen

qemu-system-x86_64 -hda disk.img -cdrom debian-6.0.3-amd64-CD-1.iso -boot c -m 3000 -smp 2 -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=/root/qemu/ifup,downscript=/root/qemu/ifdown

Iptables:

Code: Alles auswählen

iptables -t nat -A POSTROUTING -o wlan0 -s 10.0.2.101 -j SNAT --to 192.168.178.29
iptables -t nat -A POSTROUTING -o wlan0 -s 10.0.3.101 -j SNAT --to 192.168.178.29
iptables -t nat -A PREROUTING -d 192.168.178.29 -p tcp --dport 10000 -j DNAT --to 10.0.2.101:22

ip route:

Code: Alles auswählen

10.0.0.0/8 dev tap0  proto kernel  scope link  src 10.0.2.100 
10.0.0.0/8 dev tap1  proto kernel  scope link  src 10.0.3.100 
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.29

Mit der VM an tap0 kann ich 8.8.8.8 anpingen, mit der VM an tap1 kann ich nichtmal das Gateway pingen.

[r900]

ip route:

Code: Alles auswählen

10.0.0.0/8 dev tap0  proto kernel  scope link  src 10.0.2.100
10.0.0.0/8 dev tap1  proto kernel  scope link  src 10.0.3.100
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.29

Die routes müssen in dem Fall so aussehen:

Code: Alles auswählen

10.0.2.0/24 dev tap0  proto kernel  scope link  src 10.0.2.100
10.0.3.0/24 dev tap1  proto kernel  scope link  src 10.0.3.100
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.29

Oder du benutzt einfach für beide VM tap0. Eine z.B. als 10.0.2.100 10.0.2.101 und die Andere als 10.0.2.101 10.0.2.102. Dann können die auch untereinander ohne Mittelsmann kommunizieren. Oder willst du gerade das verhindern?

Nachtrag:
Die routes werden automatisch richtig gesetzt wenn du tap0 und tap1 so einrichtest:
# ifconfig tap0 10.0.2.100/24 up
# ifconfig tap1 10.0.3.100/24 up

[wanne]

Und wie immer bei solchen Fragen hier nochmal der Link der das schön alles erklärt:
https://en.wikipedia.org/wiki/Subnetwork
Im allgemeinen gilt keine 2 Interfaces im gleichen Subnet.