¿Qué se requiere exactamente para que Airplay funcione en las VLAN? [cerrado]

Parece que AirPlay funciona listo para usar, vagamente hablando, solo dentro de una LAN. No me queda claro exactamente por qué, pero parece que al menos el descubrimiento depende de las transmisiones. Wikipedia afirma que Airplay es un protocolo patentado que probablemente explica por qué la única documentación que he encontrado no es oficial como esta especificación en github .

Entonces, mis preguntas son:

1. ¿Se puede configurar una red de manera que Airplay funcione en las VLAN?
2. Si es así, ¿qué debe pasar exactamente entre las VLAN para que esto funcione?
3. ¿Es esta una mala idea en un entorno de producción dada la falta de disponibilidad de la documentación oficial del protocolo?

Hay dos cosas diferentes en el término "Airplay".

El primero trata sobre el descubrimiento de servicios y es la forma en que los dispositivos capaces de recibir transmisiones de Airplay anuncian a la red "¡Hey! ¡Puedo recibir Airplay!". Se realiza normalmente a través de un servicio llamado Bonjour (al menos Apple lo llama así) o DNS-SD . Está usando multidifusión y ese es el punto si alguien te dice que "Airplay es solo para LAN local" o algo así. La transmisión en sí es unidifusión UDP "normal".

Ahora el problema principal es cómo obtener la información sobre el receptor Airplay para los posibles remitentes en otra red. Hay dos opciones teóricas:

1. Puede reenviar multidifusión. Sin embargo, puede ser complicado, pero hay enrutadores / firewalls capaces de esto. RTFM exactamente, pero la idea es que debe reenviar el tráfico de multidifusión con la dirección de destino 224.0.0.251 a otra red y debe hacerlo sin disminuir el TTL.

2. Otra opción es utilizar DNS-SD de unidifusión. Puede usar DNS normal para anunciar la misma información que normalmente se distribuye automáticamente a través de DNS-SD de multidifusión y puede usar un poco de ayuda de la utilidad dns-sd (1) en su MacOSX para obtener información sobre qué escribir exactamente en su archivo de zona DNS . Ejecute este comando en la LAN con el receptor Airplay y esto debería darle toda la información que necesita:

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

3. También hay proxies DNS-SD (por ejemplo, avahi se puede usar como tal).

Ahora, dije "teóricamente", porque no lo he probado y haga lo que haga con protocolos, reenvíos, etc., PUEDE haber algunos obstáculos fuera de su control: después de todo, es Apple. Podría enviar toda la información correctamente al remitente potencial, pero iOS / MacOSX aún podría rechazarla porque simplemente no le gusta por alguna razón, etc.

Hay una opción más (una vez más teórica;) de fuerza bruta: cree una entrada DNS-SD para la dirección de su enrutador como un receptor Airplay para la red con remitentes Airplay y reenvíe (NAT) el flujo UDP al receptor Airplay real. Pero incluso con esto hay algunas posibilidades (para los ingenieros de Apple) de romperlo.

Continúa, pruébalo y cuéntanos tus resultados.

Este es un problema común en entornos educativos. Apple ha hecho un excelente trabajo al vender iPads y Macs a estudiantes / personal y quieren utilizar Airplay / Airprint / otras funcionalidades de Bonjour. Sin embargo, como señaló, estas características dependen de un solo dominio de difusión para el descubrimiento de servicios. Las redes empresariales / educativas simplemente no están estructuradas de esa manera.

El problema es tan frecuente que muchos miembros del personal de TI de las instituciones educativas se reunieron hace unos años y solicitaron a Apple que arregle Bonjour para que funcione mejor en estos entornos.

Para responder directamente a sus preguntas, generalmente requerirá configuraciones muy especializadas para lograr la expansión de los servicios de Airplay en su red. Y la configuración específica dependerá en gran medida de su solución inalámbrica actual (Cisco, Aerohive, Ubiquity, etc.). En general, si busca a su proveedor de servicios inalámbricos y Bonjour, debe encontrar documentación que al menos lo oriente en la dirección correcta.

He tenido un éxito mixto al implementar la solución de puerta de enlace Avahi Bonjour de Cisco , y no recomendaría investigarlo a menos que sea absolutamente necesario.

La conclusión para mí es que, como señaló en su tercera pregunta, siempre estará a merced de Apple porque este es un servicio * cerrado, patentado e indocumentado * destinado a entornos de red doméstica. Entonces, a menos que Apple decida cambiar eso, evitaría implementarlo en una red Enterprise siempre que sea posible.

_{* El código subyacente para mDNSResponder es abierto, no propietario y está disponible bajo la licencia de Apache. Sin embargo, las implementaciones de Apple de este interno en sus iDevices y MacOS están fuera de su control y podrían cambiar en cualquier momento.}

Avahi puede ayudarte aquí. Hay muchas opciones, pero esto debería llevar el tráfico a través de las subredes. Debería poder obtenerlo en un cuadro ddwrt o usar una interfaz Raspberry Pi y dot1q.

 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".

No funciona porque es una tecnología de transmisión ( multidifusión ). (ver también: Bonjour) Cruzar un dominio de difusión (es decir, VLAN) requiere un proxy. No soy una persona de Mac, pero he visto una configuración de proxy de este tipo antes, por lo que iDevices podría llegar a una impresora donde las conexiones inalámbricas y cableadas eran diferentes. No recuerdo el programa que se utilizó, pero no era gratuito.

Airplay viaja por IP, por lo que se aplica el enrutamiento normal. Necesita un enrutador para enrutar el tráfico de una VLAN a otra. Sin embargo, a menos que comience a jugar con Multicast, Bonjour permanecerá en la VLAN local.

¿Es una mala idea? Depende ;-). Tiene que contarnos mucho más sobre su entorno de producción para hacer una suposición informada.

Como otros han señalado, existe una solución gratuita de código abierto llamada Avahi ( http://www.avahi.org ) que puede funcionar como un proxy mDNS / Bonjour. La máquina en la que se ejecuta este software debe tener interfaces de red para cada VLAN / subred en la que desea que se anuncien los servicios mDNS. Sin embargo, para que los servicios reales funcionen, debe tener habilitado el enrutamiento entre VLAN o permitir conexiones TCP / UDP al dispositivo habilitado con mDNS en sus listas de acceso o firewall. Otras opciones incluyen controladores wifi de Cisco o Ubiquiti que también pueden servir como proxies mDNS, o si usa una Mac puede crear un proxy para cada servicio ( https://kb.acronis.com/sites/default/files/content/2013/ 01/39490 / wanbonjour_1.pdf) El problema con esta última solución es que debe crear un proxy para cada servicio individual, y debe rehacerlo cada vez que se reinicia la máquina.