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?