Que faut-il exactement pour que Airplay fonctionne sur les VLAN? [fermé]

Il semble qu'AirPlay ne fonctionne prêt à l'emploi, vaguement parlant, que dans un réseau local. Je ne sais pas exactement pourquoi, mais il semble qu'au moins la découverte repose sur des émissions. Wikipedia déclare que Airplay est un protocole propriétaire qui explique probablement pourquoi la seule documentation que j'ai trouvée n'est pas officielle comme cette spécification sur github .

Donc, mes questions sont:

1. Un réseau peut-il être configuré de sorte que Airplay fonctionne sur les VLAN?
2. Dans l'affirmative, qu'est-ce qui doit exactement être autorisé à passer entre les VLAN pour que cela fonctionne?
3. Est-ce une mauvaise idée dans un environnement de production étant donné l'indisponibilité de la documentation officielle du protocole?

Il y a deux choses différentes dans le terme "Airplay".

Le premier concerne la découverte de services et c'est la façon dont les appareils capables de recevoir des flux Airplay annoncent au réseau "Hé! Je peux recevoir Airplay!". Cela se fait normalement via un service appelé Bonjour (au moins Apple l'appelle ainsi) ou DNS-SD . Il utilise la multidiffusion et c'est le point si quelqu'un vous dit que "Airplay est uniquement pour le LAN local" ou quelque chose. Le streaming lui-même est unicast UDP "normal".

Maintenant, le principal problème est de savoir comment obtenir les informations sur le récepteur Airplay aux expéditeurs potentiels d'un autre réseau. Il existe deux options théoriques:

1. Vous pouvez transférer la multidiffusion. Cela peut être difficile, mais il existe des routeurs / pare-feu capables de le faire. RTFM comment exactement, mais l'idée est que vous devez transférer le trafic de multidiffusion avec l'adresse de destination 224.0.0.251 vers un autre réseau et vous devez le faire sans décrémenter TTL.

2. Une autre option consiste à utiliser DNS-SD unicast. Vous pouvez utiliser le DNS normal pour annoncer les mêmes informations normalement distribuées automatiquement via la multidiffusion DNS-SD et vous pouvez utiliser un peu d'aide de l'utilitaire dns-sd (1) sur votre MacOSX pour obtenir des informations sur ce qu'il faut exactement écrire dans votre fichier de zone DNS . Exécutez cette commande dans le LAN avec le récepteur Airplay et cela devrait vous donner toutes les informations dont vous avez besoin:

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

3. Il existe également des proxys DNS-SD (par exemple, avahi peut être utilisé comme tel).

Maintenant, j'ai dit "théoriquement", parce que je ne l'ai pas testé et quoi que vous fassiez avec les protocoles, le transfert et ainsi de suite, il pourrait y avoir des obstacles qui échappent à votre contrôle - c'est l'Apple après tout. Vous pouvez transmettre toutes les informations correctement à l'expéditeur potentiel, mais iOS / MacOSX peut toujours les rejeter car il ne les aime tout simplement pas pour une raison quelconque, etc.

Il existe une autre option (encore théorique;) de force brute - créez une entrée DNS-SD pour votre adresse de routeur en tant que récepteur Airplay pour le réseau avec des expéditeurs Airplay et transférez (NAT) le flux UDP vers le véritable récepteur Airplay. Mais même avec cela, il existe certaines possibilités (pour les ingénieurs Apple) de le casser.

Continuez, testez-le et faites-nous part de vos résultats.

Il s'agit d'un problème courant dans les environnements éducatifs. Apple a fait un excellent travail de vente d'iPad et de Mac aux étudiants / au personnel et ils souhaitent utiliser Airplay / Airprint / d'autres fonctionnalités Bonjour. Cependant, comme vous l'avez souligné, ces fonctionnalités reposent sur un seul domaine de diffusion pour la découverte de services. Les réseaux d'entreprise / d'enseignement ne sont tout simplement pas structurés de cette façon.

Le problème est si répandu que de nombreux membres du personnel informatique des établissements d'enseignement se sont réunis il y a quelques années et ont demandé à Apple de corriger Bonjour pour qu'il fonctionne mieux dans ces environnements.

Pour répondre directement à vos questions, il faudra généralement des configurations très spécialisées pour étendre les services Airplay sur votre réseau. Et la configuration spécifique dépendra fortement de votre solution sans fil actuelle (Cisco, Aerohive, Ubiquity, etc.). En général, si vous recherchez votre fournisseur de services sans fil et Bonjour, vous devriez trouver de la documentation pour au moins vous orienter dans la bonne direction.

J'ai eu un succès mitigé en déployant la solution de passerelle Avahi Bonjour de Cisco , et je ne recommanderais pas de l'examiner à moins d'y être absolument obligé.

L'essentiel pour moi est, comme vous l'avez souligné dans votre troisième question, que vous serez toujours à la merci d'Apple car il s'agit d'un service fermé, propriétaire et non documenté * destiné aux environnements de réseau domestique. Donc, à moins qu'Apple ne décide de changer cela, j'éviterais de l'implémenter dans un réseau d'entreprise autant que possible.

_{* Le code sous-jacent de mDNSResponder est ouvert, non propriétaire et disponible sous la licence Apache. Cependant, les implémentations d'Apple de cette interne à leurs iDevices et MacOS sont toutes hors de votre contrôle et pourraient changer à tout moment.}

Avahi peut vous aider ici. Il existe de nombreuses options, mais cela devrait permettre au trafic de traverser les sous-réseaux. Vous devriez pouvoir l'obtenir sur une boîte ddwrt ou utiliser des interfaces Raspberry Pi et 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".

Cela ne fonctionne pas parce que c'est une technologie de diffusion ( multidiffusion ). (voir aussi: Bonjour) La traversée d'un domaine de diffusion (c'est-à-dire VLAN) nécessite un proxy. Je ne suis pas un Mac, mais j'ai déjà vu une telle configuration de proxy - les iDevices pouvaient donc accéder à une imprimante où les réseaux sans fil et câblés étaient différents. Je ne me souviens pas du programme utilisé, mais il n'était pas gratuit.

Airplay se déplace sur IP, donc le routage normal s'applique. Vous avez besoin d'un routeur pour acheminer le trafic d'un VLAN à un autre. À moins que vous ne commenciez à jouer avec la multidiffusion, Bonjour restera cependant sur le VLAN local.

Est-ce une mauvaise idée? Ça dépend ;-). Vous devez nous en dire beaucoup plus sur votre environnement de production pour faire une supposition éclairée.

Comme d'autres l'ont noté, il existe une solution open source gratuite appelée Avahi ( http://www.avahi.org ) qui peut fonctionner comme un proxy mDNS / Bonjour. La machine sur laquelle ce logiciel fonctionne doit disposer d'interfaces réseau avec chaque VLAN / sous-réseau sur lequel vous souhaitez que les services mDNS soient annoncés vers / depuis. Cependant, pour que les services réels fonctionnent, vous devez activer le routage inter VLAN ou autoriser les connexions TCP / UDP au périphérique compatible mDNS dans vos listes d'accès ou pare-feu. Les autres options incluent les contrôleurs wifi Cisco ou Ubiquiti qui peuvent également servir de proxy mDNS, ou si vous utilisez un Mac, vous pouvez créer un proxy pour chaque service ( https://kb.acronis.com/sites/default/files/content/2013/ 01/39490 / wanbonjour_1.pdf). Le problème avec cette dernière solution est que vous devez créer un proxy pour chaque service individuel, et vous devez le refaire à chaque redémarrage de la machine.