Traffic anderer Hosts in CT sichtbar

[tomic]

Hallo,

ich teste aktuell Proxmox 4.2 und bin dabei auf folgendes gestoßen:
Ich sehe in den lxc Containern den Traffic der zu diesem gehörenden Node über tcpdump.

Beispiel (schaulbild siehe skizze2.jpg)

Host 1 /etc/network/interfaces (BRIDGED)

Spoiler

auto lo
iface lo inet loopback

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
address 94.XXX.XXX.151
netmask 255.255.255.224
gateway 94.XXX.XXX.129
bridge_ports eth0
bridge_stp off
bridge_fd 0

auto vmbr0:1
iface vmbr0:1 inet static
address 10.11.0.11
netmask 255.255.0.0

Host 2 /etc/network/interfaces (ROUTED)

Spoiler

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 94.XXX.XXX.152
netmask 255.255.255.224
pointopoint 94.XXX.XXX.129
gateway 94.XXX.XXX.129

# 1. Sub-Interface
auto eth0:1
iface eth0:1 inet static
address 10.11.0.12
netmask 255.255.0.0

Host 3 /etc/network/interfaces (ROUTED)

Spoiler

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 94.XXX.XXX.153
netmask 255.255.255.224
pointopoint 94.XXX.XXX.129
gateway 94.XXX.XXX.129

# 1. Sub-Interface
auto eth0:1
iface eth0:1 inet static
address 10.11.0.13
netmask 255.255.0.0

CT1 /etc/network/interfaces

Spoiler

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 94.XXX.XXX.141
netmask 255.255.255.224
gateway 94.XXX.XXX.129

CT2 /etc/network/interfaces

Spoiler

auto venet0
iface venet0 inet manual
up ifconfig venet0 up
up ifconfig venet0 127.0.0.2
up route add default dev venet0
down route del default dev venet0
down ifconfig venet0 down

iface venet0 inet6 manual
up route -A inet6 add default dev venet0
down route -A inet6 del default dev venet0

auto venet0:0
iface venet0:0 inet static
address 94.xxx.xxx.142
netmask 255.255.255.255

auto venet0:1
iface venet0:1 inet static
address 10.11.0.102
netmask 255.255.255.255

Wenn ich nun einen Ping von Host 2 auf Host 1 über das 10ner Netz mache, sehe ich diesen Ping auch in CT1. Auch wenn ich von Host2 auf Host3 Traffic erzeuge, ist dies ebenfalls in CT1 auf Host1 sichtbar. In CT2 und CT3 habe ich das Problem nicht, das hat vermutlich etwas mit Bridged/Routed zu tun?

In einer Hosting-Umgebung ist es natürlich fatal, dass ein Container den Traffic der anderen Container sieht.
Gibt es hierfür vielleicht eine Möglichkeit, im Container auch wirklich nur das an Traffic zu sehen, was diesen Container etwas "angeht"? Was müsste ich umstellen oder wie müsste mein Netzwerk aufgebaut sein?

Vielen Dank im Voraus.

 

[pixelpeter]

Hallo tomic,

Ja das geht. du musst openvswitch nutzen.
Nur so bekommst du eine saubere Trennung hin.

Peter

 

[wbumiller]

Ja das geht. du musst openvswitch nutzen.
Nur so bekommst du eine saubere Trennung hin.

Passiert mir ohne openvswitch auch nicht. Ist auch keine lösung sondern ein weglaufen vom problem.
Am besten mal genau den traffic analysieren und sehen welche art von paketen überhaupt durchgehen. Die ersten ARP requests zb auf addressen die der bridge vorher noch nicht bekannt waren sind auf allen bridge ports sichtbar. Bis die ziele dann mal bekannt sind. Immerhin sollten sich bridges wie switches verhalten sofern man ageing nicht auf 0 gesetzt hat, wodurch sie sich dann wie ein hub verhalten. Welche addressen die bridges gelernt haben sieht man mit `brctl showmacs vmbrXY`. Dann wärs auch gut zu wissen was die container selbst rausschicken, eventuell liegt da ein problem?

 

[tomic]

Auf dem Interface in der CT sehe ich nur den"10er" Traffic der anderen Host-Nodes. Der Traffic aus dem 94er Netz wird richtigerweise bis auf einmalige "arp who-has Requests" nicht in der CT als Traffic angezeigt. Die CT, in welcher ich aktuell die Messungen durchführe, ist nur zu diesem Zweck aufgesetzt und macht tatsächlich nichts im Netzwerk.

brctl showmacs vmbr0

Spoiler

# brctl showmacs vmbr0
port no mac addr is local? ageing timer
1 00:0a:f3:6a:70:00 no 0.00
1 00:15:17:fb:22:c8 yes 0.00
1 00:15:17:fb:22:c8 yes 0.00
1 00:1e:67:07:56:28 no 0.93
1 00:1e:67:0f:af:fc no 1.14
1 00:1e:67:4a:9d:20 no 1.94
1 00:25:90:2f:28:16 no 2.23
1 00:25:90:2f:8e:e8 no 9.38
1 00:25:90:f3:af:56 no 7.88
1 00:25:90:f6:59:81 no 1.43
3 2a:4d:af:b4:36:10 no 122.56
2 3a:7f:6a:76:e5:f4 no 102.41
1 4c:72:b9:24:5d:97 no 0.00
1 8c:89:a5:80:fb:2d no 4.16
1 f0:1c:2d:e8:15:03 no 19.82
2 fe:20:84:b2:2d:c8 yes 0.00
2 fe:20:84:b2:2d:c8 yes 0.00
3 fe:75:76:08:58:18 yes 0.00
3 fe:75:76:08:58:18 yes 0.00

Ist es vielleicht einfach nur so, dass diese Sub-Interface-Geschichte nicht sauber mit der Bridged-Konfiguration funktioniert? Wäre eine Lösung, dass ich das 10er Netz mit einem zusätzlichen Switch auf eth1 als tatsächlich eigenes Netz abbilde? Natürlich wäre das sowieso sauberer, aber eben auch teurer.

 

[wbumiller]

Von und zu welcher mac addressen gehn dabei die pakete aus dem 10er netzwerk die nicht sichtbar sein sollten im vergleich zu den ARP Hello messages vom jeweils zugehörigen container?

Und sind nodes 2 und 3 pve3? Wegen 'venet' in der config. (Was ja auf host 1 / ct 1 keinen einfluss haben sollte, trotzdem interessant zu wissen.)

 

[tomic]

Auf Node 2+3 läuft noch ein PVE3.4.

Aktuell habe ich zu Testzwecken mit Openvswitch experimentiert und mittels Firewall den unerwünschten Traffic zur CT erfolgreich unterbunden. Kann aber meiner Einschätzung nach nicht die Lösung sein, oder?

Beispiel aus dem TCP Dump in CT1 (FW disabled)

09:18:48.562799 IP 10.11.0.12.5404 > 239.192.80.138.5405: UDP, length 75
09:18:48.563094 IP 10.11.0.12.5404 > 239.192.80.138.5405: UDP, length 1473
09:18:48.563099 IP 10.11.0.12 > 239.192.80.138: ip-proto-17
09:18:48.563138 IP 10.11.0.12.5404 > 239.192.80.138.5405: UDP, length 1473
09:18:48.563141 IP 10.11.0.12 > 239.192.80.138: ip-proto-17
09:18:48.563188 IP 10.11.0.12.5404 > 239.192.80.138.5405: UDP, length 1473
09:18:48.563191 IP 10.11.0.12 > 239.192.80.138: ip-proto-17
09:18:48.563195 IP 10.11.0.12.5404 > 239.192.80.138.5405: UDP, length 1473
09:18:48.563199 IP 10.11.0.12 > 239.192.80.138: ip-proto-17
09:18:48.563204 IP 10.11.0.12.5404 > 239.192.80.138.5405: UDP, length 687
09:18:48.565576 IP 10.11.0.12.5404 > 239.192.80.138.5405: UDP, length 781

Zur Erinnnerung:
10.11.0.12 ist Node 3 (pve3 mit venet)

MAC-Adresse von Node 3
00:1e:67:0f:af:fc

Durch die ovswitch-Konfiguration kann ich leider keine MAC-Tabelle mehr ausgeben.
brctl showmacs "egal welche" -> read of forward table failed: Operation not supported

 

[dcsapak]

die ip 239.192.80.138 ist eine multicast adresse (siehe http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml#multicast-addresses-12),
daher ist es klar, dass der container die pakete auch bekommt

 

[tomic]

soweit habe ich auch schon recherchiert, es ist jedoch so, dass eine CT auf Node2 und Node3 diesen Traffic nicht mitbekommt und die CT auf Node1 mit Bridged Mode eben schon.

 

[wbumiller]

In dem fall liegt das an der bridge. Über ein routed venet setup kommen keine multicast pakete so weit ich weiß.
Wie genau eine bridge mit multicast paketen umgeht hängt von ein paar variablen ab und dem zustand in dem sie ist. Wenn sie keine informationen hat sollten die pakete an alle ports weitergeleitet werden. Wenn multicast_snooping (/sys/class/net/vmbr0/bridge/multicast_snooping) an ist, dann sollten nur ports die vorher ein multicast group join paket geschickt haben den traffic bekommen - sofern die bridge weiß, dass so eine gruppe existiert, hängt also auch damit zusammen was für traffic die bridge vorher schon mitbekommen hat.