So könnte es gehen
Bitte nicht übel nehmen, aber nachdem ich dieser Tage stillschweigend mitgelesen habe, scheint es mir, als fehlt es am grundlegenden Verständnis für bestimmte netzwerktechnische Grundlagen und v.a. am Verständnis für die Funktionsweise von Multicast, IGMP und des IGMPProxy, wobei mir zugegebenermaßen persönlich letzteres auch noch nicht 100%ig geläufig ist.
Ich habe mir daher in den letzten 2 Tagen den Kopf über die korrekte Umsetzung der Problematik zerbrochen und entsprechende Manuals zum IGMPProxy gelesen, habe allerdings selber noch keinen Test durchführen können, ob meine theoretischen Überlegungen korrekt sind oder nicht.
Versuchen wir's zusammenzutragen:
Serverseitig(serversite) = T-Home Anschluss mit IPTV
Servernetz: 192.168.110.0/24 (/24 entspricht Netzmaske 255.255.255.0)
Lokale IP Adresse Router(serversite): $ip_local_router_serversite
Lokale IP Adresse Media Receiver(serversite): $ip_local_mr_serversite
Remote IP Adresse Router(serversite): $ip_remote_router_serversite (ggf. durch DynDNS-Name ersetzen)
Clientseitig(clientsite) = x-belieber DSL Anschluss mit Media Receiver im Netzwerk
Clientnetz: 192.168.200.0/24 (/24 entspricht Netzmaske 255.255.255.0)
Lokale IP Adresse Router(clientsite): $ip_local_router_clientsite
Lokale IP Adresse Media Receiver(clientsite): $ip_local_mr_clientsite
Remote IP Adresse Router(clientsite): $ip_remote_router_clientsite (ggf. durch DynDNS-Name ersetzen)
Beide Netze sind über VPN Tunnel miteinander verbunden, angeschlossene Hosts können untereinander kommunizieren.
Soviel zur Vorbereitung.
Grundlagen:
Ein Media Receiver kann seinen jew. IPTV Stream nur emfpangen, wenn er einer entsprechenden Multicast Gruppe beitreten/sie wieder verlassen/einer anderen Gruppe beitreten kann. Die Verwaltung dieser Multicast Gruppen erfolgt über IGMP im Router, die Übertragung des Streams selber wird dann über ein Multicast-Routing Protokoll ermöglicht, welches das Routing zwischen den Routern vornimmt. Welches Protokoll das konkret bei T-Home Entertain ist, ist mir nicht ersichtlich, m.E. nach dürfte es PIM sein.
Umsetzung:
Damit also der clientseitige MediaReceiver streamen kann, müssen seine IGMP Anfragen ("IGMP Daten") über den Tunnel in das Serverseitige Netz geroutet werden. Dies wird vermutlich clientseitig mit IGMPProxy realisiert. Vorraussetzung ist, dass der multid im Router mit der Option -i (disable IGMP proxy), also ohne hauseigene IGMPProxy-Funktion gestartet wird. Also konfigurieren wir clientseitig das Tunneling Interface als Upstream Interface für IGMPProxy und geben als Zielnetzwerk das Remote Netz, ergo das Servernetz an. IGMPProxy muss auch noch wissen, an welche NIC's im Clientnetz der Multicast Stream geroutet werden darf. IGMPProxy leitet allen ankommenden Multicast Traffic an alle Interfaces weiter, die in der Konfiguration als Downstream Interface werden. Also deklarieren wir ethX (wobei X=0-3 ist, je nachdem, an welchem LAN Port der MediaReceiver angeschlossen ist) als Downstream Interface serverseitig. Es kann auch ein zweites oder drittes Downstream Interface deklariert werden, falls mehr Clients Multicast empfangen sollen. Das ist aber aufgrund der Bandbreitenanforderungen kaum praktikabel, aber auf jeden Fall erwähnenswert und später auch noch notwendig. Dazu einfach eine weitere Konfigurationszeile in der Konfiguration anlegen.
Client-Konfig:
Code:
quickleave
phyint tun0 upstream ratelimit 0 threshold 1
## Subnetz des Server-Netzes
altnet 192.168.110.0/24
phyint lanX downstream ratelimit 0 threshold 1
Serverseitig muss weiterhin der gewünschte Multicast Stream ("Multicast Traffic") ins Clientseitige Netz geroutet werden. Demzufolge muss serverseitig ebenfalls IGMPProxy zum Einsatz kommen. Nochmal zur Erinnerung: IGMPProxy leitet allen ankommenden Multicast Traffic an alle Interfaces weiter, die in der Konfiguration als Downstream Interface deklariert sind. Also deklarieren wir das Tunneling Interface serverseitig als ein Downstream Interface. Natürlich wollen wir im serverseitigen Netz ebenfalls Multicast Traffic entfangen, also müssen alle NIC's im Servernetz ebenfalls als Downstream Interface deklariert werden.
Server-Konfig:
Code:
## Downstream Interface für tun0
phyint tun0 downstream ratelimit 0 threshold 1
## Downstream Interface für lanX (MR des Server Netzes)
phyint lanX downstream ratelimit 0 threshold 1
Jetzt müssen "nur" noch serverseitig alle IGMP Anfragen Richtung T-Home geroutet werden. Ich vermute das Routing dahin, hat bisher der IGMPProxy von mutltid übernommen, diesen haben wir aber deaktiviert. Also muss IGMPProxy das für uns übernehmen. Als Upstream Interface wird serverseitig also das "dsl" Interface deklariert und eine Route in das entfernte Netz konfiguriert. Doch in welches Netz soll geroutet werden?
Hier scheiden sich jetzt die Geister bzw. bin ich mir selber unschlüssig. Aufgrund der zahlreichen Beiträge vermutete ich als Zielnetz das häufig zitierte Netz 193.158.35.0/24. Und tatsächlich taucht eine IP-Adresse aus dieses Netz im Tracelog meines VLAN 8 (siehe Anlage) auf und das nicht zu selten! Allerdings ist jene Adresse niemals eine Ziel-Adresse geschweige denn werden irgendwelche IGMP Anfragen dorthin geroutet. Stattdessen werden über UDP die Multicast Nutzdaten ankommend geroutet. Was passiert aber mit den IGMP Anfragen? Mein Trace sagt: Umschaltvorgang = source-IP: meine per DHCP zugewiesene IP-Adresse, Destination: 224.0.0.X, Protocoll IGMP <= das ist Multicast Traffic!
Demzufolge liegt der Verdacht nahe, dass Serverseitig kein "altnet" angegeben werden muss, denn das Routing von Multicast Traffic zwischen Serverseitigen Router und Backbone Router übernimmt offensichtlich das bereits oben erwähnte Multicast-Routing Protokoll.
Ab hier gilt es jetzt also, auszuprobieren:
Entweder
Server-Config ohne Angabe einer Route serverseitig
Code:
quickleave
## Downstream Interface für tun0
phyint tun0 downstream ratelimit 0 threshold 1
## Downstream Interface für lanX (MR des Server Netzes)
phyint lanX downstream ratelimit 0 threshold 1
phyint dsl upstream ratelimit 0 threshold 1
oder
Server-Config mit Route ins Netz 193.158.35.0/24
Code:
quickleave
## Downstream Interface für tun0
phyint tun0 downstream ratelimit 0 threshold 1
## Downstream Interface für lanX (MR des Server Netzes)
phyint lanX downstream ratelimit 0 threshold 1
phyint dsl upstream ratelimit 0 threshold 1
altnet 193.158.35.0/24
wobei ich letzteres theoretisch ausschliese.
Bitte korrigiert mich, wenn ich grobe Denkfehler habe. Ich habe das ganze bisher nur theoretisch durchgespielt und außer meinem Tracelog und den Manuals man igmpproxy und man igmpproxy.conf keine weiteren Quellen (abgesehen von den üblichen Informationsseiten).
Ergänzende Hinweise:
Ich habe in einem Forum gelesen, dass angeblich die Reihenfolge in der igmpproxy.conf eine Rolle spielt. Es soll wohl zunächst das/die Downstream Interface(s) zuerst deklariert werden, danach erst das Upstream Interface. Ich persönliche glaube aber, dass das Unfug ist.
In allen möglichen Konfigurationen wurde Serverseitig im Upstream Interface eine Route ins Clientnetz konfiguriert. Warum erschliest sich mir nicht ganz. Vmtl. hat hier einfach der "Ich-copy/paste-einfach-mal-ne-Konfiguration-und-schaue-was-dabei-rauskommst-Fehlerteufel" zugeschlagen. Das führt natürlich schnell zu Verwirrungen und Verständnisproblemen. wenn natürlich jemand eine logische Erklärung dazu hat, dann immer her damit.
@-ChriZ
Könntest du das ganze bitte so wie beschrieben testen?! Achte vor allem darauf, dass dein Downstream Interface korrekt konfiguriert ist, denn dieses war m.E. nach bisher falsch konfiguriert (es muss heisen "lanX"; X=0-3 und nicht nur "lan"). Außerdem muss multid ohne Hauseigenen IGMPProxy restartet werden.
