[fli4l] Multicast-Pakete - was macht der Router damit?

[Stefan Puschek]

Hallo Christoph,

Christoph Schulz <fli4l at kristov.de> schrieb:
… 
>> ich habe vor, hier intern einen Musik-Server mit IP-Multicasting
>> aufzusetzen. Es sollen nur INTERNE clients den Stream empfangen.
>> 
>> Aber was macht der Router mit einem Paket, das als Zieladresse
>> irgendwas zwischen 224.0.0.0 und 239.255.255.255 hat? Ich will nur
>> vermeiden, dass der Stream nach draussen gelangt.
> 
> Multicast ist eine "Wissenschaft" für sich. Ich bin da nicht gerade der 
> Experte (und es scheint ohnehin vergleichsweise wenige "da draußen" zu 
> geben), aber ich habe mich gezwungenermaßen mit dem Thema beschäftigt, da 
> ich bei fli4l für die IPv6-Integration verantwortlich zeichne und in IPv6 
> Multicast gleich fest im Protokoll-Stapel eingebaut ist (Stichwort MLD-
> Protokoll).

das mit der Wissenschaft glaube ich Dir mittlerweile…

> Generell ist es so, dass sich Clients für Multicast aktiv "registrieren" 
> müssen. D.h. Clients teilen dem Netz über bestimmte Protokolle (IGMP bei 
> IPv4, MLD bei IPv6) mit, dass sie an dem Empfang bestimmter Streams 
> interessiert sind. Dabei werden spezielle Multicast-Adressen benutzt 
> (hauptsächlich 224.0.0.0/3, wie du geschrieben hast, bei IPv6 ist es 
> FF00::/8), wobei spezielle einzelne Adressen darin bestimmten Multicast-
> Gruppen entsprechen, die teilweise eine feste Bedeutung haben (die Gruppe 
> aller erreichbaren DHCP-Server, die Gruppe aller erreichbaren Router etc.). 
> Diese Registrierung erfolgt über IGMP/MLD-Pakete an bestimmte Multicast-
> Adressen (d.h. bestimmte Adressen sind für die IGMP/MLD-Mechanismen selbst 
> reserviert). Der Router horcht auf diesen speziellen Adressen, bekommt das 
> mit und merkt sich die Registrierung. Wenn nun Multicast-Pakete an eine 
> bestimmte Adresse verschickt werden, schaut der Router nach, welche Clients 
> sich für die entsprechende Gruppe registriert haben, und leiten die Pakete 
> dorthin weiter. Somit entspricht Multicast letztlich einem kontrollierten 
> Broadcast: kontrolliert, weil Clients sich explizit anmelden müssen.
> 
> Das ist natürlich nur vereinfacht dargestellt, weil gewisse Konfigurationen 
> das Ganze verkomplizieren. Zum Beispiel will man vermeiden, dass diese 
> Pakete sich über Bridges unnötig "vervielfachen", so dass i.d.R. Bridges 
> auch auf IGMP/MLD horchen (Stichwort IGMP Snooping) und sich merken, wo der 
> eigentliche Client sitzt, damit die Pakete nicht an alle Teilnehmer einer 
> Bridge weitergeleitete werden müssen, sondern nur an die "interessierten". 
> Aber das große Bild sollte stimmen.

so habe ich das mittlerweile auch verstanden

>> Muss ich hier im Paketfilter eingreifen, oder wie unterbinde ich, dass
>> mein Stream nach draussen geht?
> 
> Nun, damit der Stream nach draußen geht, müssten IGMP/MLD-Anmeldungen von 
> außen in den fli4l hineinkommen. Da ich nicht davon ausgehe, dass du diese 
> Protokolle (IGMP ist ein auf IP basiertes Protokoll wie TCP oder UDP auch, 
> es hat die Protokoll-Nummer 2; bei MLD ist das etwas komplizierter, da das 
> Protokoll ins ICMPv6-Protokoll eingebettet ist) in deiner INPUT-Kette 
> explizit erlaubst (es sei denn, dein fli4l soll ebenfalls irgendwelche 
> Multicast-Gruppen verwalten, weil ein Multicast-fähiger Dienst auf dem fli4l 
> läuft), solltest du keine Probleme erwarten. 

ich hatte eigentlich nur Angst, dass der Router die Pakete einfach nach draussen 
schickt, weil die Zieladresse ja nicht intern ist. Versuche mit traceroute 
verliefen zwar negativ, aber ich weiss nicht warum…

Warum wird ein Paket an 225.226.227.228 nicht einfach "genattet" ? Pakete an 
10.11.12.13 schickt er ja auch nach draussen (mein LAN hat 192.168.6.0/24). 

Also habe ich im PF eine Regel hinzugefügt:

    PF_FORWARD_7='any 224.0.0.0/4 DROP NOLOG'

damit sollten _NIEMALS_ irgendwelche Multicasting-Pakete nach draussen gehen - 
oder irre ich?

> Ich hoffe, dir irgendwie geholfen zu haben ;-)

ja sicher - vielen Dank

> Viele Grüße,

Groetjes
Stefan