XEN, iptables und MASQUERADE

[Baer]

Hallo miteinander
Ich hab mir Xen installiert und es funktioniert eigentlich gut, ausser das masquerading nicht läuft.
Er läuft auf meinem "Server" welcher auch als Router fungiert und direkt am Cablemodem hängt.

Code: Alles auswählen

$IPT -t nat -A POSTROUTING -o eth1 -j MASQUERADE

ist meine masquerading Regel, das Interface stimmt, sonst würde es mit den Physischen Maschienen ja auch nicht laufen

./network-bridge status gibt folgendes aus:

Code: Alles auswählen

============================================================
13: eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue 
    link/ether 00:30:18:a4:aa:25 brd ff:ff:ff:ff:ff:ff
    inet 192.168.15.75/24 brd 192.168.15.255 scope global eth3
    inet6 fe80::230:18ff:fea4:aa25/64 scope link 
       valid_lft forever preferred_lft forever
18: xenbr1: <BROADCAST,NOARP,UP,10000> mtu 1500 qdisc noqueue 
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::200:ff:fe00:0/64 scope link 
       valid_lft forever preferred_lft forever
 
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              vif0.1
                                                        peth3
                                                        vif1.0
 
192.168.15.0/24 dev eth3  proto kernel  scope link  src 192.168.15.75 
192.168.14.0/24 dev eth2  proto kernel  scope link  src 192.168.14.75 
192.168.13.0/24 dev eth0  proto kernel  scope link  src 192.168.13.75 
84.75.96.0/20 dev eth1  proto kernel  scope link  src 84.75.x.x
default via 84.75.x.x dev eth1 
 
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.15.0    0.0.0.0         255.255.255.0   U     0      0        0 eth3
192.168.14.0    0.0.0.0         255.255.255.0   U     0      0        0 eth2
192.168.13.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
84.75.x.x      0.0.0.0         255.255.240.0   U     0      0        0 eth1
0.0.0.0         84.75.x.x      0.0.0.0         UG    0      0        0 eth1
============================================================

tcpdump meint:

Code: Alles auswählen

 tcpdump  host  jc-in-f99.google.com -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
16:47:01.226671 IP 192.168.15.24 > jc-in-f99.google.com: ICMP echo request, id 57092, seq 862, length 64

also unmaskiert

hat jemand eine Idee??

grüässli Urs

eine interessante Beobachtung ist noch :

Code: Alles auswählen

$IPT -t nat -A PREROUTING -i $WAN -p tcp --dport 22  -j DNAT  --to-destination 192.168.15.24
$IPT  -A FORWARD -i $WAN -o $XEN   -j ACCEPT

funktioniert

[DynaBlaster]

Code: Alles auswählen

$IPT -t nat -A POSTROUTING -o eth1 -j MASQUERADE

ist meine masquerading Regel, das Interface stimmt, sonst würde es mit den Physischen Maschienen ja auch nicht laufen

Wie soeht denn deine FORWARD-Chain aus. Die MASQUERADE-Regel allein reicht nicht, du musst die Pakete auch in der FORWARD-CHAIN durchlassen. Poste am besten mal das ganze Script nach http://nopaste.debianforum.de/

[Baer]

für den Test habe ich diese Forwardingroule drinnen

Code: Alles auswählen

$IPT  -A FORWARD -i $WAN -o $XEN   -j ACCEPT

normalerweise diese:

Code: Alles auswählen

$IPT -A WAN-XEN -m state --state ESTABLISHED,RELATED -j ACCEPT

aber soweit kommen die Pakete gar nicht, weil:

Code: Alles auswählen

 tcpdump  host  jc-in-f99.google.com -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
16:47:01.226671 IP 192.168.15.24 > jc-in-f99.google.com: ICMP echo request, id 57092, seq 862, length 64

eth1 ist mein WAN interface, hier sollte also meine öffentliche IP erscheinen.

danke und grüässli
Urs

[DynaBlaster]

Code: Alles auswählen

$IPT  -A FORWARD -i $WAN -o $XEN   -j ACCEPT

Wie gesagt: ohne das komplette Script kann man nur mutmassen, was genau sich hinter $WAN und $XEN verbirgt. Der Codeschnipsel oben scheint jedenfalls für den Rückweg der Pakete bestimmt zu sein. Was ist mit dem Hinweg? Die POSTROUTING-Regel allein reicht nicht. Da müsste noch etwa in der Art von dem hier sein:

Code: Alles auswählen

$IPT -A FORWARD -i $XEN -o $WAN -j ACCEPT

[Baer]

hallo DynaBlaster
Das gesamte Skript ist ziemlich lange (vier Netzwerkkarten plus eine Virtuelle für VPN auf dem wirtsystem.)
$XEN --> eth3 --> Interface zu den Domus
$WAN --> eth1 --> WAN interface
WAN-XEN --> eigene Chain für Verkehr vom wan zum xen Netzerk
umgekert existiert Natürlich auch.

Im überigen Netzwerk Läuft alles bestens, ink Masquerading.
Netzwerk Verkehr im lokalen Netz (drei subnetze) alles bestens.
Verbindung von aussen zu den Domu's mit DNAT prächtig!
Nur das masquerading der Domus geht nicht.
Der Trafic wird geroutet (sihe tcp dump) aber nicht maskiert.
zum Vergleich die Tcpdumpusgabe eines funktionierenden pings von meinem Notebook welchs über den selben Server/Router und das selbe Wan Interface ins Internet geht.

Code: Alles auswählen

tcpdump host  py-in-f99.google.com  -i eth1 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
18:49:30.461478 IP 84-75-99-xxx.dclient.hispeed.ch > py-in-f99.google.com: ICMP echo request, id 33053, seq 16, length 64
18:49:30.583801 IP py-in-f99.google.com > 84-75-99-xxx.dclient.hispeed.ch: ICMP echo reply, id 33053, seq 16, length 64

Ich sehe also, die Pings der domu werden zwar geroutet und werden bei eth1 ins Internet an google geschickt, aber sind nach wie vor mit der privaten Absenderadresse versehen und werden entsprechend im öffentlichen Netz nicht geroutet.

das Problem liegt beim Masquerading welches nicht angewendet wird. Wahrscheinlich ein Problem mit den virtuellen Intervaces die durch die xenbridge erstellt werden


liäbs grüässli und vielen dank für deine Mühen Urs

[DynaBlaster]

Okay, so langsam steige ich durch das Setup durch - dummerweise habe ich aber keine Lösung für das Problem und kann mir auch nicht wirklich erklären, warum sich iptables so verhält und sich weigert den Traffic der XEN-DomU's zu maskieren.

Ähnlich wie du, vermute ich allerdings auch, dass das Verhalten irgendwie mit der Bridge, die von XEN angelegt wird zusammenhängen muss. Eine Möglichkeit, dieses Problem zu umgehen, könnte ein geroutetes (statt gebridgtes) XEN-Setup sein. Ich hatte sowas mal am laufen und die Konfigurationshinweise finden sich hier:
http://www.debianforum.de/forum/viewtop ... highlight=

Vielleicht bringt dich das ja weiter.

[Baer]

die Idee mit dem routing werde ich mir mal genauer anschauen, hoffentlich bringt das die Lösung. Das mit dem Masquerading ist aber trozdem ziemlich schräg zumal eth1 eigentlich gar nichts mit der Bridge zu tun hat (sie läuft auf eth3).
Das Xen Forum ist mir auch noch nicht über den Weg gelaufen, ist in die Linksamlung aufgenommen.

liäbs Grüässli Urs

[tobi_w]

Hallo!
Ich hatte auch Probleme mit der Bridge. Ich weiß aber nicht mehr welche es waren.
In meiner Firewall seht folgendes:

Code: Alles auswählen

$IPTABLES -A FORWARD -m physdev --physdev-in peth+ -j ACCEPT
$IPTABLES -A FORWARD -m physdev --physdev-in vif+ -j ACCEPT
$IPTABLES -t raw -A PREROUTING -i xenbr0 -j NOTRACK

Die ersten beiden Regeln sind dafür da, damit das Forwarding innerhalb der Bridge funktioniert. Wenn Forward so oder so für alles auf ACCEPT steht braucht man die nicht.

Versuche erst mal die NOTRACK-Regel. Die habe ich mir irgendwo aus dem Xen-Forum gezogen, aber ich weiß nicht was genau die bewirkt. Hat irgendwas mit nat zu tun.
Kann die vieleicht jemand erklären???

Ansonsten poste doch mal die Ausgaben von:

Code: Alles auswählen

$IPTABLES -n -v -L
$IPTABLES -t nat -n -v -L

[Baer]

HEUREKA

ist das nicht herrlich?

Code: Alles auswählen

tcpdump host  py-in-f99.google.com  -i eth1 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:45:03.433936 IP 84-75-99-105.dclient.hispeed.ch > py-in-f99.google.com: ICMP echo request, id 27654, seq 50, length 64
11:45:03.556739 IP py-in-f99.google.com > 84-75-99-105.dclient.hispeed.ch: ICMP echo reply, id 27654, seq 50, length 64

Danke Tobi !!
die Nottrack Regel wars, es läuft!

Kannst du mir einen Hint geben, Was das bedeutet? Würd mich wegen dem Verständnis interessieren?


Dank auch nochmals an DynaBlaster

Grüässli Urs