Was genau ist erforderlich, damit Airplay über VLANs hinweg funktioniert? [geschlossen]

Anscheinend funktioniert AirPlay nur innerhalb eines LANs. Mir ist nicht genau klar, warum, aber es sieht so aus, als ob Entdeckung auf Sendungen beruht. Wikipedia gibt an, dass Airplay ein proprietäres Protokoll ist, das wahrscheinlich erklärt, warum die einzige Dokumentation, die ich gefunden habe, inoffiziell ist, wie diese Spezifikation bei github .

Meine Fragen lauten also:

1. Kann ein Netzwerk so konfiguriert werden, dass Airplay über VLANs hinweg funktioniert?
2. Wenn ja, was genau muss zwischen den VLANs passieren dürfen, damit dies funktioniert?
3. Ist dies eine schlechte Idee in einer Produktionsumgebung, da keine offizielle Protokolldokumentation verfügbar ist?

Es gibt zwei verschiedene Dinge im Begriff "Airplay".

In der ersten geht es um die Diensterkennung und darum, wie Geräte, die Airplay-Streams empfangen können, dem Netzwerk die Meldung "Hey, ich kann Airplay empfangen!" Dies geschieht normalerweise über einen Dienst namens Bonjour (zumindest von Apple so genannt) oder DNS-SD . Es wird Multicast verwendet und das ist der Punkt, an dem Ihnen jemand sagt, dass "Airplay nur für lokales LAN geeignet ist" oder so. Das Streaming selbst ist "normales" UDP-Unicast.

Das Hauptproblem ist nun, wie Sie die Informationen über den Airplay-Empfänger an die potenziellen Absender in einem anderen Netzwerk weiterleiten. Es gibt zwei theoretische Möglichkeiten:

1. Sie können Multicast weiterleiten. Es mag schwierig sein, aber es gibt Router / Firewalls, die das können. RTFM wie genau, aber die Idee ist, dass Sie Multicast-Verkehr mit der Zieladresse 224.0.0.251 an ein anderes Netzwerk weiterleiten müssen, und Sie müssen dies tun, ohne die TTL zu verringern.

2. Eine andere Option ist die Verwendung von Unicast-DNS-SD. Sie können normales DNS verwenden, um die gleichen Informationen anzukündigen, die normalerweise automatisch über Multicast-DNS-SD verteilt werden. Mithilfe des Dienstprogramms dns-sd (1) auf Ihrem MacOSX können Sie Informationen darüber abrufen, was genau in Ihre DNS-Zonendatei geschrieben werden soll . Führen Sie diesen Befehl im LAN mit Airplay-Empfänger aus und Sie sollten alle Informationen erhalten, die Sie benötigen:

   $ dns-sd -Z _airplay._tcp
   Browsing for _airplay._tcp
   ...
   

3. Es gibt auch DNS-SD-Proxys (zum Beispiel kann avahi als solches verwendet werden).

Jetzt habe ich "theoretisch" gesagt, weil ich es nicht getestet habe und was auch immer Sie mit Protokollen, Weiterleitungen usw. tun, es KÖNNTE einige Hindernisse geben, die sich Ihrer Kontrolle entziehen - es ist schließlich der Apple. Sie könnten alle Informationen korrekt an den potenziellen Absender weiterleiten, aber iOS / MacOSX könnte sie dennoch ablehnen, weil sie ihm aus irgendeinem Grund einfach nicht gefallen und so weiter.

Es gibt noch eine (wieder theoretische) Brute-Force-Option: Erstellen Sie einen DNS-SD-Eintrag für Ihre Router-Adresse als Airplay-Empfänger für das Netzwerk mit Airplay-Sendern und leiten Sie den UDP-Stream (NAT) an den echten Airplay-Empfänger weiter. Aber auch damit gibt es einige Möglichkeiten (für Apple-Ingenieure), es zu brechen.

Machen Sie weiter, testen Sie es und teilen Sie uns Ihre Ergebnisse mit.

Dies ist ein häufiges Problem in Bildungsumgebungen. Apple hat seine iPads und Macs hervorragend an Studenten / Mitarbeiter verkauft und sie möchten Airplay / Airprint / andere Bonjour-Funktionen nutzen. Wie Sie bereits betont haben, sind diese Funktionen für die Serviceerkennung auf eine einzige Broadcast-Domäne angewiesen. Unternehmens- / Bildungsnetzwerke sind einfach nicht so strukturiert.

Das Problem ist so weit verbreitet, dass sich viele IT-Mitarbeiter von Bildungseinrichtungen vor einigen Jahren versammelten und Apple ersuchten, Bonjour zu reparieren , um in diesen Umgebungen besser arbeiten zu können.

Um Ihre Fragen direkt beantworten zu können, sind normalerweise sehr spezielle Konfigurationen erforderlich, um die Airplay-Dienste in Ihrem Netzwerk zu verteilen. Die spezifische Konfiguration hängt stark von Ihrer aktuellen Wireless-Lösung ab (Cisco, Aerohive, Ubiquity usw.). Wenn Sie nach Ihrem Mobilfunkanbieter und Bonjour suchen, sollten Sie im Allgemeinen eine Dokumentation finden, die Sie zumindest in die richtige Richtung weist.

Die Implementierung der Avahi Bonjour-Gateway-Lösung von Cisco war nicht ganz erfolgreich. Ich würde es nicht empfehlen, sie zu prüfen, es sei denn, Sie müssen es unbedingt.

Wie Sie in Ihrer dritten Frage ausgeführt haben, sind Sie unter dem Strich immer Apple ausgeliefert, da es sich um einen geschlossenen, proprietären undokumentierten Dienst * handelt, der für Heimnetzwerkumgebungen vorgesehen ist. Wenn Apple dies nicht ändern möchte, würde ich es nach Möglichkeit vermeiden, es in einem Unternehmensnetzwerk zu implementieren.

_{* Der zugrunde liegende Code für mDNSResponder ist offen, nicht proprietär und unter der Apache-Lizenz verfügbar. Die Implementierungen von Apple für diese internen iDevices und MacOS-Geräte liegen jedoch außerhalb Ihrer Kontrolle und können jederzeit geändert werden.}

Avahi kann Ihnen hier weiterhelfen. Es gibt viele Optionen, aber dies sollte den Datenverkehr über die Subnetze leiten. Sie sollten in der Lage sein, es auf eine ddwrt-Box zu bekommen oder eine Raspberry Pi und dot1q-Schnittstelle zu verwenden.

 enable-reflector= Takes a boolean value ("yes"  or  "no").  If  set  to
       "yes"  avahi-daemon  will  reflect  incoming mDNS requests to all local
       network interfaces, effectively allowing clients to browse  mDNS/DNS-SD
       services  on  all  networks  connected  to  the gateway. The gateway is
       somewhat intelligent and should work with all kinds  of  mDNS  traffic,
       though  some functionality is lost (specifically the unicast reply bit,
       which is used rarely anyway). Make sure to not run multiple  reflectors
       between the same networks, this might cause them to play Ping Pong with
       mDNS packets. Defaults to "no".

 reflect-ipv= Takes a boolean value ("yes" or "no"). If set to "yes" and
       enable-reflector  is  enabled,  avahi-daemon  will forward mDNS traffic
       between IPv4 and IPv6, which is usually not  recommended.  Defaults  to
       "no".

Es funktioniert nicht, weil es sich um eine Broadcast ( Multicast ) -Technologie handelt. (Siehe auch: Bonjour) Das Überqueren einer Broadcast-Domain (dh eines VLAN) erfordert einen Proxy. Ich bin kein Mac-Benutzer, aber ich habe schon einmal ein solches Proxy-Setup gesehen - damit iDevices auf einen Drucker zugreifen können, auf dem WLAN und Kabel unterschiedliche LANs haben. Ich erinnere mich nicht an das verwendete Programm, aber es war nicht kostenlos.

Airplay wird über IP übertragen, daher gilt normales Routing. Sie benötigen einen Router, um Datenverkehr von einem VLAN zu einem anderen weiterzuleiten. Bonjour bleibt jedoch im lokalen VLAN, es sei denn, Sie beginnen mit Multicast zu spielen.

Ist das eine schlechte Idee? Es hängt davon ab, ob ;-). Sie müssen uns viel mehr über Ihre Produktionsumgebung erzählen, um eine fundierte Vermutung anzustellen.

Wie andere angemerkt haben, gibt es eine kostenlose Open-Source-Lösung namens Avahi ( http://www.avahi.org ), die als mDNS / Bonjour-Proxy fungieren kann. Die Maschine, auf der diese Software ausgeführt wird, muss über Netzwerkschnittstellen zu jedem VLAN / Subnetz verfügen, für das / von dem mDNS-Dienste angekündigt werden sollen. Damit die eigentlichen Dienste jedoch funktionieren, muss das Inter-VLAN-Routing aktiviert sein oder TCP / UDP-Verbindungen zum mDNS-fähigen Gerät in Ihren Zugriffslisten oder der Firewall zugelassen sein. Weitere Optionen sind Cisco- oder Ubiquiti-WLAN-Controller, die auch als mDNS-Proxys dienen können. Wenn Sie einen Mac verwenden, können Sie für jeden Dienst einen Proxy erstellen ( https://kb.acronis.com/sites/default/files/content/2013/). 01/39490 / wanbonjour_1.pdf). Das Problem bei dieser letzten Lösung besteht darin, dass Sie für jeden einzelnen Dienst einen Proxy erstellen und ihn bei jedem Neustart des Computers erneut ausführen müssen.