Propagation multicast à travers un bridge

Support Debian
#1

Résumé de la question: Y’a-t-il un filtrage sur des interfaces montées en bridge? Je pensais que c’était complètement transparent.

Détails:

Je vous rappelle mon paquet ecoute ( question-sur-un-paquet-eventuel-t37897.html ) que j’utilise régulièrement et qui remplit parfaitement son rôle. Cependant je viens de le tester dans une nouvelle configuration:

3 machines:
192.168.1.251 serveur DHCP avec une interface en bridge br0 = eth0 + tap0, non concernée par le pbm à mon avis.$ route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 10.8.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap1 82.66.248.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 239.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 br0 0.0.0.0 82.66.248.254 0.0.0.0 UG 0 0 0 eth1

192.168.1.248: avec une interface eth0 montée en pont avec une interface wlan0 montée en point d’accès WIFI:

[code]# ifconfig
br0 Link encap:Ethernet HWaddr 00:01:c0:08:6d:62
inet adr:192.168.1.248 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::201:c0ff:fe07:6d62/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:103097562 errors:0 dropped:0 overruns:0 frame:0
TX packets:193234916 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:27714725395 (25.8 GiB) TX bytes:280912657039 (261.6 GiB)

eth0 Link encap:Ethernet HWaddr 00:01:c0:08:6d:62
adr inet6: fe80::201:c0ff:fe07:6d62/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:159471707 errors:0 dropped:0 overruns:0 frame:0
TX packets:231744009 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:105451926322 (98.2 GiB) TX bytes:285977790085 (266.3 GiB)

eth1 […]
mon.wlan0 Link encap:UNSPEC HWaddr 00-0D-F0-64-0D-5A-6C-6F-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13193460 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:3249229701 (3.0 GiB) TX bytes:0 (0.0 B)

wlan0 Link encap:Ethernet HWaddr 00:0d:f0:64:0d:5a
adr inet6: fe80::20d:f0ff:fe63:d5a/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39563302 errors:0 dropped:0 overruns:0 frame:0
TX packets:65886834 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:1294171699 (1.2 GiB) TX bytes:2193058566 (2.0 GiB)
[/code](eth1 ne sert pas). Table de routage simplissime,

# route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.1.251 0.0.0.0 UG 0 0 0 br0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 aucune règle iptables, toutes les polices par défault à ACCEPT.

Sur une machine branchée sur le réseau j’emet des paquets udp multicast: Je vois ces paquets sur la passerelle, sur toute machine branchée par cable sur le réseau, donc aussi sur la machine 192.168.1.248 que ce soit par

tcpdump -i br0 host 225.0.0.17 mais ces paquets ne passent pas le bridge alors même que tout le reste passe. En fait je vois ces paquets par

tcpdump -i eth0 -n host 225.0.0.17 10:18:15.106423 IP 192.168.1.245.57582 > 225.0.0.17.1960: UDP, length 13 mais pas par

tcpdump -i wlan0 -n host 225.0.0.17 ni br0.
Par contre tout le reste du trafic si. Ça signifie que le multicast serait bloqué au niveau du bridge et là je ne vois pas où agir. Je me rappelle vaguement Pascal disant quelque chose à ce sujet mais j’ai grillé mon dernier neurone sur ça il y a longtemps.

#2

C’est un peu confus, tu as deux machines avec des ponts et on ne sait pas trop sur laquelle ça passe ou pas, sur quelles interfaces les paquets sont visibles ou pas. Il semble manquer des morceaux dans ton texte : “que ce soit” suggère une alternative, mais il n’y a qu’un terme.

Concernant le filtrage des paquets pontés, certains types de paquets passent par netfilter donc iptables si les réglages correspondants dans /proc/sys/net/bridge/ sont activés (c’est le cas par défaut). Je n’ai pas connaissance de traitement particulier des paquets multicast par le pontage du noyau.

#3

Je me souvenais de l’application des règles iptables sur le bridge et de son aspect non logique mais ici ça n’est pas ça je pense. Il me semblait que tu avais dit qque chose à propos du broadcast ou du multicast mais c’est un lointain souvenir. En gros en résumant tu as

192.168.1.251 serveur DHCP (avec une interface en bridge sur un VPN tap0 mais ça n’a pas d’influence). Non concernée par le souci, mais cela montre que le DHCP passe sans problème le pont de 192.168.1.248 (voir après)

192.168.1.248 avec un point d’accès sur wlan0 en bridge avec eth0, relié par cable sur le réseau LAN et donc faisant point d’accès WIFI

192.168.1.237 sur le LAN via WIFI (connecté via le point d’accès de 192.168.1.248).

192.168.1.245 sur le LAN par cable qui émet des UDP multicast

Le paquets se repère sur 192.168.1.248, 192.168.1.251 dès qu’on enlève le parefeu, mais pas sur 192.168.1.237. Si on fait sur 192.168.1.248 un tcpdump, on voit passer les paquets sur br0, sur eth0 mais pas sur wlan0 (j’ignore ce que donne un tcpdump sur une interface spécifique lorsqu’elle est en bridge). La machine est parfaitement connecté pour tout le reste, seul le multicast semble bloqué.

Je viens d’essayer le broadcast, lui aussi est bloqué, un ping -b 192.168.1.255 est vu sur 192.168.1.248 mais pas sur 192.168.1.237. Il y a un blocage à ce stade on dirait.

Sur 192.168.1.248:
Aucune règle de parefeu (tout à accept, iptables-save vide)

[code]/proc/sys/net/bridge# ls | awk ‘{print “echo “$1”: $(cat “$1”)”}’ | sh
bridge-nf-call-arptables: 1
bridge-nf-call-ip6tables: 1
bridge-nf-call-iptables: 1
bridge-nf-filter-pppoe-tagged: 0
bridge-nf-filter-vlan-tagged: 0
bridge-nf-pass-vlan-input-dev: 0

iptables-save

Generated by iptables-save v1.4.8 on Mon Mar 4 16:04:21 2013

*nat
:PREROUTING ACCEPT [12582:2052557]
:INPUT ACCEPT [55:3244]
:OUTPUT ACCEPT [80:6463]
:POSTROUTING ACCEPT [8782:818257]
COMMIT

Completed on Mon Mar 4 16:04:21 2013

Generated by iptables-save v1.4.8 on Mon Mar 4 16:04:21 2013

*filter
:INPUT ACCEPT [9725:1447046]
:FORWARD ACCEPT [155580]
:OUTPUT ACCEPT [6574:2176511]
COMMIT

Completed on Mon Mar 4 16:04:21 2013

hercule:/proc/sys/net/bridge#
[/code]

#4

Bon, si je remplace l’adresse multicast par l’adresse 192.168.1.237 de la machine, ça passe très bien. C’est vraiment un blocage du multicast au niveau du pont.

Le noyau est compilé avec CONFIG_IP_MULTICAST, je n’ai pas vu d’option non mise semblant en rapport.

#5

Je pense que c’est plus l’adresse MAC multicast de la trame ethernet que l’adresse IP qui pose problème. A tout hasard, tu as regardé du côté des options d’IGMP snooping (cf. linuxfoundation.org/collabor … ing/bridge) ?
Edit: apparemment ça n’a été introduit qu’à partir du noyau 2.6.34.