Forum: PC Hard- und Software Linux, multicast addresse auf anderes Interface forwarden


von Daniel A. (daniel-a)


Angehängte Dateien:

Lesenswert?

Hallo zusammen

Zunächst, ein Netzwerkdiagramm mit den wichtigsten Geräten ist im 
Anhang.

Ich habe einen Raspberry PI mit einer Kamera, der steht draussen. Aus 
Sicherheitsgründen habe ich den in ein separates WLan und Netz gepackt, 
mein IoT Netz. Der IoT W-Lan AP ist ein anderer Raspberry PI, im 
Erdgeschoss, der leitet alles über vlan 99 im LAN Netz zu meinem Server 
auf dem Dachboden weiter, auf dem in Containern und VMs DNS, DHCP, usw. 
Server laufen.
Auf dem Server auf dem Dachboden habe ich eine Firewall, mit der lasse 
ich Verbindungen vom LAN ins IoT Netz zu, aber nicht umgekehrt. So kann 
ich also vom LAN Netz aus, über den Server, über vlan 99 übers LAN 
zurück zum IoT W-Lan AP, und von dort auf den PI draussen zugreifen.

Jetzt will ich aber das Bild vom PI mit möglichst geringer Latenz, 
möglichst real time, und ohne längere Aussetzer/Verzögerung wenn mal ein 
Packet Verloren geht, auf mehreren Geräten im LAN Netz anzeigen. Der PI 
mit der Kamera soll also per UDP (Unicast oder Multicast ist egal), erst 
mal den Stream zum Raspberry PI, der den IoT W-Lan AP bereitstellt, 
senden.
Dieser soll dann den Stream, und nur diesen, nicht wie alles andere über 
den VLAN zum Server weiterleiten, sondern direkt an eine Multicast 
Addresse ins LAN schaufeln. Das soll direkt der Kernel machen, denn ich 
will möglichst wenig Latenz. Leider ist das der Punkt, an dem ich gerade 
nicht weiter komme.

Auf dem Raspberry PI habe ich folgende Netzwerkconfig:

/etc/network/interfaces
1
auto lo
2
iface lo inet loopback
3
4
auto eth0
5
iface eth0 inet dhcp
6
7
auto wlan0
8
iface wlan0 inet manual
9
  hostapd /etc/hostapd/iot.conf
10
11
auto eth0.99
12
iface eth0.99 inet manual
13
14
auto br-iot
15
iface br-iot inet static
16
  bridge_ports eth0.99 wlan0
17
  address 10.60.2.5
18
  netmask 255.255.255.0
19
  gateway 10.60.2.1

Der Videostream kommt bei wlan0 rein, und soll bei eth0 raus. Die 
Zieladresse soll sein 239.1.2.50, port 5004. Ob ich den Stream per 
Multicast 239.1.2.50 port 5004 an den PI senden muss, oder ob das per 
Unicast an wlan0 10.60.2.5 port 5004 ankommt, spielt für mich keine 
Rolle, wichtig ist nur, dass es bei eth0 per Multicast raus kommt.

Rein mit iptables-nft konnte ich noch keine Lösung dafür finden.

Das, was einer Lösung bisher am nächsten kam, war eth0 in die Bridge zu 
schieben, und dann sämtliches unerwünschtes Forwarding abzuschalten:
1
#!/usr/sbin/iptables-restore
2
*filter
3
:INPUT ACCEPT [90132:5101782]
4
:FORWARD DROP [9251:2005247]
5
:OUTPUT ACCEPT [88032:6539899]
6
-A FORWARD -d 239.1.2.50/32 -p udp -m udp -m physdev --physdev-out eth0 -j ACCEPT
7
-A FORWARD -d 239.1.2.50/32 -p udp -m udp -m physdev --physdev-out eth0.99 -j DROP
8
-A FORWARD -m physdev --physdev-in wlan0 --physdev-out eth0.99 -j ACCEPT
9
-A FORWARD -m physdev --physdev-in eth0.99 --physdev-out wlan0 -j ACCEPT
10
COMMIT

Leider fehlen dann aber noch Regeln, für Verbindungen direkt zum PI, und 
Verbindungen ausgehend vom PI, also alles, was nicht geforwarded wird.

Eigentlich müsste ich bei eth0 alles Blockieren, was nicht über vlan 99 
kommt oder geht. Womöglich braucht es auch noch etwas arp filtering. 
Aber ich konnte iptables-nft noch nicht dazu bringen, mir nach vlans zu 
filtern. Meine switches kommen auch überhaupt nicht damit klar, die 
werden komplett unerreichbar (kein arp oder ping auf diese, sie switchen 
ansonsten aber noch einwandfrei), wenn sie die selben Packete vom PI 
selbst auf mehreren interfaces und einem vlan sehen. So komme ich also 
auch nicht weiter.

Etwas anderes, das ich noch probiert habe, ist mroute mit dem smcroute 
tool einzustellen. (Die iptables Regeln habe ich vorher natürlich wieder 
entfernt, und eth0 aus der bridge wieder heraus genommen.).

/etc/smcroute.conf:
1
phyint eth0 enable
2
phyint br-iot enable
3
mgroup from br-iot source 10.60.2.50 group 239.1.2.50
4
mroute from br-iot source 10.60.2.50 group 239.1.2.50 to eth0

"smroutectl show" zeigt die Route auch an, und wenn ich den Stream 
starte, zählt auch der Counter der empfangenen Pakete hoch. Mit tcpdump 
sehe ich auch, wie die auf br-iot ankommen, aber bei eth0 kommen leider 
keine Pakete raus.

Ich habe schon versucht zu setzen:
1
echo 0 > /sys/devices/virtual/net/br-iot/bridge/multicast_snooping
2
sysctl net.ipv4.ip_forward=1
rp_filter ist schon überall auf 0. Das brachte aber alles keine 
Änderung. Die TTL der ankommenden Pakete ist auch hoch genug (16).

Was könnte ich noch versuchen?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Ich habe es nun hin bekommen.

/etc/network/interfaces:
1
auto lo
2
iface lo inet loopback
3
4
auto lan--iot
5
iface lan--iot inet manual
6
  pre-up ip link add lan--iot type veth peer name iot--lan
7
  up ip link set dev lan--iot up
8
  up ip link set dev iot--lan up
9
  down ip link set dev lan--iot down
10
  down ip link set dev iot--lan down
11
  post-down ip link del lan--iot
12
13
auto eth0
14
iface eth0 inet manual
15
16
auto wlan0
17
iface wlan0 inet manual
18
  hostapd /etc/hostapd/iot.conf
19
20
auto eth0.99
21
iface eth0.99 inet manual
22
23
auto br-lan
24
iface br-lan inet dhcp
25
  bridge_ports lan--iot eth0
26
  bridge_fd 0
27
28
auto br-iot
29
iface br-iot inet static
30
  bridge_ports iot--lan eth0.99 wlan0
31
  bridge_fd 0
32
  address 10.60.2.5
33
  netmask 255.255.255.0
34
  gateway 10.60.2.1

iptables:
1
#!/usr/sbin/iptables-restore
2
# Generated by xtables-save v1.8.2 on Fri Jan 22 23:11:32 2021
3
*mangle
4
:PREROUTING ACCEPT [183675:170007112]
5
:INPUT ACCEPT [119875:125774346]
6
:FORWARD ACCEPT [203271:212685217]
7
:OUTPUT ACCEPT [20501:8322553]
8
:POSTROUTING ACCEPT [206911:198989677]
9
-A PREROUTING -d 239.1.2.50/32 -p udp -j TOS --set-tos 0x10/0x2e
10
-A PREROUTING -d 239.1.2.50/32 -p udp -j DSCP --set-dscp 0x2e
11
-A PREROUTING -p udp -m udp --dport 5004 -j TOS --set-tos 0x10/0x2e
12
-A PREROUTING -p udp -m udp --dport 5004 -j DSCP --set-dscp 0x2e
13
COMMIT
14
# Completed on Fri Jan 22 23:11:32 2021
15
# Generated by xtables-save v1.8.2 on Fri Jan 22 23:11:32 2021
16
*filter
17
:INPUT ACCEPT [99821:99212728]
18
:FORWARD ACCEPT [186761:190740630]
19
:OUTPUT ACCEPT [20501:8322553]
20
-A INPUT -p udp -m udp --dport 5004 -m physdev --physdev-in lan--iot -j ACCEPT
21
-A INPUT -d 239.1.2.50/32 -p udp -m physdev --physdev-in lan--iot -j ACCEPT
22
-A INPUT -m physdev --physdev-in iot--lan -j DROP
23
-A INPUT -m physdev --physdev-in lan--iot -j DROP
24
-A FORWARD -d 239.1.2.50/32 -o br-iot -p udp -m udp -m physdev ! --physdev-in iot--lan -j DROP
25
COMMIT
26
# Completed on Fri Jan 22 23:11:32 2021
27
# Generated by xtables-save v1.8.2 on Fri Jan 22 23:11:32 2021
28
*nat
29
:PREROUTING ACCEPT [0:0]
30
:INPUT ACCEPT [0:0]
31
:POSTROUTING ACCEPT [0:0]
32
:OUTPUT ACCEPT [0:0]
33
-A PREROUTING -i br-iot -p udp -m udp --dport 5004 -j DNAT --to-destination 239.1.2.50
34
COMMIT
35
# Completed on Fri Jan 22 23:11:32 2021

smcroute brauch ich trotzdem noch. Keine ahnung, warum.

Sowohl ankommendes unicast als auch multicast wird nun schön geroutet, 
und es scheint als wird auch nicht mehr geforwarded, als ich will.

Die Switches verabschieden sich trotzdem wieder, irgendwo ist also noch 
der wurm drin. Vieleicht kommen sie dinger auch einfach nicht mit 
grossen Mengen multicast traffic zurecht. Das multicast verhält sich 
momentan auch noch nicht richtig, die Switches und die Bridges auf dem 
Server reagieren wie ein hub, broadcasten das multicast überal hin. 
Dabei habe ich doch extra das IGMP snooping eingestellt, da muss ich 
auch noch schauen, was da los ist. Irgendwoher kommt auch immer noch ein 
1-2s Sekunden delay rein, und bei manchen Netzwerkpfaden gehen viele der 
udp Pakete verloren...

Aber immerhin hat sich das Routing Problem erledigt.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.