Что именно требуется для работы Airplay в VLAN? [закрыто]

Похоже, AirPlay работает «из коробки», если говорить смутно, только внутри локальной сети. Мне не совсем понятно, почему, но похоже, что, по крайней мере, открытие опирается на трансляции. Википедия утверждает, что Airplay - это собственный протокол, который, вероятно, объясняет, почему единственная документация, которую я нашел, является неофициальной, как эта спецификация на github .

Итак, мои вопросы:

1. Можно ли настроить сеть таким образом, чтобы Airplay работал через VLAN?
2. Если это так, что именно должно быть разрешено проходить между VLAN для этой работы?
3. Является ли это плохой идеей в производственной среде, учитывая недоступность официальной документации протокола?

В термине "Airplay" есть две разные вещи.

Первый - об обнаружении сервиса, и именно так устройства, способные принимать потоки Airplay, сообщают сети «Эй! Я могу получать Airplay!». Обычно это делается через службу Bonjour (по крайней мере, Apple так называет) или DNS-SD . Он использует многоадресную рассылку, и в этом смысл, если кто-то говорит вам, что «Airplay предназначен только для локальной сети» или что-то в этом роде. Сама потоковая передача является «обычным» одноадресным 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 и Mac студентам / сотрудникам, которые хотят использовать Airplay / Airprint / другие функции Bonjour. Однако, как вы указали, эти функции полагаются на один широковещательный домен для обнаружения службы. Предприятие / образовательные сети просто не структурированы таким образом.

Проблема настолько распространена, что многие ИТ-специалисты образовательных учреждений собрались несколько лет назад и обратились к Apple с просьбой помочь Bonjour лучше работать в этих средах.

Чтобы напрямую ответить на ваши вопросы, обычно требуются очень специализированные конфигурации для обеспечения охвата служб Airplay в вашей сети. И конкретная конфигурация будет сильно зависеть от вашего текущего беспроводного решения (Cisco, Aerohive, Ubiquity и т. Д.). В общем, если вы ищете своего поставщика услуг беспроводной связи и Bonjour, вы должны найти документацию, которая, по крайней мере, укажет вам правильное направление.

У меня был неоднозначный успех при развертывании решения Cisco Avahi Bonjour gateway , и я бы не советовал изучать его, если это абсолютно не нужно.

Суть в том, что, как вы указали в своем третьем вопросе, вы всегда будете зависеть от Apple, потому что это закрытая, закрытая, недокументированная услуга *, предназначенная для сред домашней сети. Поэтому, если Apple не решит это изменить, я бы по возможности не использовал его в корпоративной сети.

_{* Базовый код для mDNSResponder является открытым, не проприетарным и доступен по лицензии Apache. Тем не менее, реализация Apple этого внутреннего устройства для iDevices и MacOS находится вне вашего контроля и может измениться в любое время.}

Авахи может помочь вам здесь. Есть много вариантов, но это должно получить трафик через подсети. Вы должны быть в состоянии получить его на коробке 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). Проблема с этим последним решением заключается в том, что вам необходимо создать прокси-сервер для каждой отдельной службы и повторять его каждый раз при перезагрузке компьютера.