Що саме потрібно, щоб Airplay працював у VLAN? [зачинено]

Схоже, AirPlay працює нестандартно, нечітко кажучи, лише в локальній мережі. Мені точно не зрозуміло, чому, але схоже, що принаймні відкриття покладається на трансляції. У Вікіпедії зазначено, що Airplay - це власницький протокол, який, ймовірно, пояснює, чому єдина документація, яку я знайшов, є неофіційною, як ця специфікація в github .

Отже, мої запитання:

1. Чи можна налаштувати мережу таким чином, що Airplay працює у VLAN?
2. Якщо так, то що саме потрібно дозволити проходити між локальними мережами VLAN, щоб зробити цю роботу?
3. Це погана ідея у виробничому середовищі, враховуючи відсутність офіційної протокольної документації?

У терміні "Airplay" є дві різні речі.

Перший - про виявлення сервісу, і саме про те, як пристрої, здатні приймати потоки Airplay, оголошують мережу "Ей, я можу отримувати Airplay!". Зазвичай це робиться через сервіс під назвою Bonjour (принаймні Apple так називає) або DNS-SD . Це використання мультимедійних повідомлень, і ось у чому справа, якщо хтось скаже вам, що "Послух в ефірі призначений лише для локальної локальної мережі" чи щось таке. Сам потік - це "звичайний" UDP одноадресний.

Тепер основна проблема полягає в тому, як ви отримуєте інформацію про приймач Airplay потенційним відправникам в іншій мережі. Є два теоретичні варіанти:

1. Ви можете переслати багатоадресову передачу. Це може бути складним, але є маршрутизатори / брандмауери, здатні на це. RTFM як саме, але ідея полягає в тому, що вам доведеться пересилати трафік багатоадресної пошти з адресою призначення 224.0.0.251 в іншу мережу, і ви повинні це робити без зменшення кількості TTL.

2. Іншим варіантом є використання одноадресної DNS-SD. Ви можете використовувати звичайний DNS, щоб оголосити ту саму інформацію, яка зазвичай автоматично поширюється через багатоадресний DNS-SD, і ви можете скористатися невеликою допомогою утиліти dns-sd (1) на вашому MacOSX, щоб отримати інформацію про те, що саме потрібно записати у файл DNS-зони. . Виконайте цю команду в локальній мережі за допомогою приймача Airplay, і це має дати вам всю необхідну інформацію:

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

3. Є також проксі-сервери DNS-SD (наприклад, avahi може використовуватися як такий).

Тепер я сказав "теоретично", тому що я цього не перевіряв, і все, що ви робите з протоколами, переадресацією тощо, МОЖЕ бути якісь дорожні блоки поза вашим контролем - це все-таки Apple. Ви можете правильно отримати всю інформацію потенційному відправнику, але iOS / MacOSX все одно може відхилити її, оскільки вона чомусь просто не подобається тощо.

Існує ще одна (знову теоретична, хоча;) груба сила - створити запис DNS-SD для своєї адреси маршрутизатора як приймач Airplay для мережі з відправниками Airplay та передати (NAT) потік UDP на реальний приймач Airplay. Але навіть при цьому є деякі можливості (для інженерів Apple) зламати це.

Продовжуйте тестування та повідомте нам про ваші результати.

Це поширена проблема в освітніх середовищах. Apple зробила відмінну роботу з продажу iPad та Macs студентам / персоналу, і вони хочуть використовувати функцію Airplay / Airprint / інший Bonjour. Однак, як ви зазначали, ці функції для виявлення послуги покладаються на єдиний домен широкомовної передачі. Підприємницькі / освітні мережі просто не структуровані таким чином.

Проблема настільки поширена, що багато працівників ІТ навчального закладу зібралися кілька років тому і звернулися з проханням Apple, щоб змусити Bonjour працювати краще в цих умовах.

Для прямого вирішення ваших запитань, як правило, знадобляться спеціалізовані конфігурації, щоб виконати розповсюдження служб Airplay у вашій мережі. А конкретна конфігурація буде сильно залежати від вашого поточного бездротового рішення (Cisco, Aerohive, Ubiquity тощо). Загалом, якщо ви шукаєте свого постачальника послуг бездротового зв’язку та Bonjour, вам слід знайти документацію, щоб принаймні вказати вас у правильному напрямку.

Я мав неоднозначний успіх при застосуванні шлюзового рішення Avahi Bonjour від Cisco , і не рекомендував би вивчати це, якщо вам абсолютно не доведеться.

Підсумок мені, як ви зазначали у своєму третьому запитанні, завжди будете на милість Apple, оскільки це закрита, власна, незадокументована послуга *, призначена для домашніх мереж. Отже, якщо Apple не вирішить це змінити, я б уникав цього впроваджувати в мережі Enterprise, де це можливо.

_{* Основний код для mDNSResponder відкритий, непатентований та доступний за ліцензією Apache. Однак реалізація цього внутрішнього пристрою Apple для своїх iDevices та MacOS - поза вашим контролем і може змінитися в будь-який час.}

Тут вам може допомогти Avahi . Варіантів дуже багато, але це повинно отримати трафік по підмережах. Ви повинні мати можливість отримати його на вікні ddwrt або використовувати Raspberry Pi та інтерфейси 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".

Це не працює, оскільки це широкомовна ( багатоадресна ) технологія. (див. також: Bonjour) Для переходу широкомовного домену (тобто VLAN) потрібен проксі. Я не людина Mac, але раніше я бачив таку налаштування проксі-сервера, щоб iDevices міг потрапити на принтер, де бездротові та провідні були різні програми. Я не пам’ятаю програми, яку використовували, але вона не була безкоштовною.

Airplay подорожує по IP, тому застосовується звичайна маршрутизація. Вам потрібен маршрутизатор для маршрутизації трафіку з однієї VLAN в іншу. Якщо ви не почнете возитися з Multicast, Bonjour залишиться на локальній VLAN.

Це погана ідея? Це залежить ;-). Ви повинні сказати нам набагато більше про ваше виробниче середовище, щоб зробити здогадку здогаданою.

Як зазначають інші, існує безкоштовне рішення з відкритим кодом під назвою Avahi ( http://www.avahi.org ), яке може працювати як проксі-сервер mDNS / Bonjour. Машина, на якій працює це програмне забезпечення, повинна мати мережеві інтерфейси до кожної VLAN / підмережі, до якої ви хочете, щоб послуги mDNS рекламувалися / з. Для того, щоб фактичні сервіси працювали, проте, у вас повинно бути включено маршрутизацію між VLAN або дозволити підключення TCP / UDP до пристрою з підтримкою mDNS у списках доступу або брандмауері. Інші варіанти включають в себе контролери Wi-Fi Cisco або Ubiquiti, які також можуть бути проксі-серверами mDNS, або за допомогою Mac можна створити проксі для кожної служби ( https://kb.acronis.com/sites/default/files/content/2013/ 01/39490 / wanbonjour_1.pdf). Проблема з цим останнім рішенням полягає в тому, що вам потрібно створити проксі-сервер для кожної окремої служби, і вам доведеться її повторно виконувати кожного разу при перезавантаженні машини.