Airplay가 VLAN에서 작동하도록하려면 무엇이 정확히 필요합니까? [닫은]


17

AirPlay가 LAN 내에서만 모호하게 작동하는 것처럼 보입니다. 왜 그런지는 분명하지 않지만 적어도 발견은 방송에 의존하는 것처럼 보입니다. Wikipedia에 따르면 Airplay는 독점 프로토콜로 , 내가 찾은 유일한 문서가 왜 github의이 사양 과 같이 비공식적인지 설명 할 수 있습니다 .

그래서 내 질문은 :

  1. Airplay가 VLAN에서 작동하도록 네트워크를 구성 할 수 있습니까?
  2. 그렇다면 VLAN을 통과하기 위해 정확히 무엇을 허용해야합니까?
  3. 공식 프로토콜 문서를 사용할 수 없기 때문에 프로덕션 환경에서 이것이 나쁜 생각입니까?

1
응용 프로그램은 '신뢰할 수있는'네트워크에 신뢰할 수있는 장치가 있고 '방문자'무선 네트워크에있는 다른 장치가있는 사무실입니다. 두 네트워크의 장치는 중역 TV로 Airplay 할 수 있어야합니다.
alx9r

환경에 대한 자세한 내용을 추가 할 수 있습니까? 예를 들어, 어떤 브랜드의 무선 장비를 사용하고 있습니까? 이것은 당신의 능력에 큰 영향을 미칩니다.
Brett Lykins

1
해당 vlan에서 해당 회의실에 대한 Apple TV를 사용하여 회의실 당 SSID / VLAN을 작성하십시오. 또는 게스트 SSID에 직접 배치하고 프레젠테이션 중에 직원에게 연결하십시오. 그런 다음 회의실을 사용하는 사람은 누구나 해당 네트워크에서 프리젠 테이션을 할 수 있습니다. 내부 직원은 설정에 따라 내부 리소스에 액세스하기 위해 내부 네트워크에 VPN을 연결할 수 있습니다.
some_guy_long_gone

@legioxi이 시점에서 최고의 계획입니다. 모든 봉쥬르 장치는 게스트 네트워크에 있으며 신뢰할 수있는 사용자 RA-VPN은 필요할 경우 필요에 따라 신뢰할 수있는 네트워크에 들어갑니다. 여전히 두 네트워크 모두에서 프린터를 사용할 수있게하는 문제가 있지만 지금까지는 가장 최악의 전략 인 것 같습니다.
alx9r

1
이는 시스코 제품에 '서비스 디스커버리 게이트웨이'라고 - cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dns/configuration/...
cpt_fink

답변:


7

"Airplay"라는 용어에는 두 가지가 있습니다.

첫 번째는 서비스 검색에 관한 것이며 Airplay 스트림을 수신 할 수있는 장치가 "Hey! I Air를받을 수 있습니다!"라는 네트워크에 알리는 방법입니다. Bonjour (적어도 Apple은 그렇게 부릅니다) 또는 DNS-SD 라는 서비스를 통해 정상적으로 수행됩니다 . 멀티 캐스트를 사용하고 있으며 누군가 "Airplay는 로컬 LAN 전용입니다"라고 말하고있는 경우입니다. 스트리밍 자체는 "정상"UDP 유니 캐스트입니다.

이제 주요 문제는 Airplay 수신기에 대한 정보를 다른 네트워크의 잠재적 인 발신자에게 얻는 방법입니다. 두 가지 이론적 옵션이 있습니다.

  1. 멀티 캐스트를 전달할 수 있습니다. 비록 까다로울 수 있지만 이것을 가능하게하는 라우터 / 방화벽이 있습니다. RTFM은 얼마나 정확하지만 아이디어는 대상 주소가 224.0.0.251 인 멀티 캐스트 트래픽 을 다른 네트워크로 전달해야하며 TTL을 줄이지 않고 수행해야한다는 것입니다.

  2. 다른 옵션은 유니 캐스트 DNS-SD를 사용하는 것입니다. 일반 DNS를 사용하면 멀티 캐스트 DNS-SD를 통해 자동으로 자동 배포되는 동일한 정보를 알릴 수 있으며 MacOSX의 dns-sd (1) 유틸리티에서 약간의 도움을 받아 DNS 영역 파일에 정확히 무엇을 쓸 수 있는지 정보를 얻을 수 있습니다 . Airplay 수신기가있는 LAN에서이 명령을 실행하면 필요한 모든 정보가 제공됩니다.

    $ dns-sd -Z _airplay._tcp
    Browsing for _airplay._tcp
    ...
    
  3. DNS-SD 프록시도 있습니다 (예 : avahi를 그대로 사용할 수 있음).

이제는 이론적으로 테스트하지 않았기 때문에 프로토콜, 전달 등으로 수행 한 모든 작업을 제어 할 수없는 장애물이있을 수 있습니다. 결국 애플입니다. 잠재적 인 발신자에게 모든 정보를 올바르게 가져올 수 있지만 iOS / MacOSX는 어떤 이유로 든 정보가 마음에 들지 않기 때문에 거부 할 수 있습니다.

무차별 강제 옵션이 하나 더 있습니다. Airplay 발신자와 네트워크의 Airplay 수신자로 라우터 주소에 대한 DNS-SD 항목을 생성하고 UDP 스트림을 실제 Airplay 수신자에게 전달합니다. 그러나 이것조차도 (애플 엔지니어에게는) 그것을 깨뜨릴 수있는 가능성이 있습니다.

계속해서 테스트하고 결과에 대해 알려주십시오.


어. 따라서 귀하의 평가에 따라이 작업을 얻는 것은 기본적으로 실험으로 귀결됩니다.
alx9r

1
당신은 문서화되지 않은 장소에 있으므로 항상 실험에 관한 것입니다. 애플은 그것을 지원하지 않기 때문에 (업데이트 등으로) 순간을 망칠 수도 있습니다. 그러나 할 일에 대해 배우고 이해하고 안전하게 만들 수 있으며 고장이 나면 다시 작동하게 할 수 있습니다. 또는 적어도 왜 정확히 작동시킬 수 없는지 이해하십시오.).
Thom

두 번째 단락의 마지막 요점 : 이 게시물 은 "... AppleTV는 검색이 작동하더라도 자체 서브넷 외부에서 연결되지 않습니다 ..."를 나타냅니다.
alx9r

6

이것은 교육 환경에서 일반적인 문제입니다. Apple은 iPad / Mac을 학생 / 직원에게 판매하는 훌륭한 일을 해왔으며 Airplay / Airprint / 기타 Bonjour 기능을 활용하려고합니다. 그러나 지적했듯이 이러한 기능은 서비스 검색을 위해 단일 브로드 캐스트 도메인에 의존합니다. 기업 / 교육 네트워크는 그렇게 구성되지 않았습니다.

이 문제는 너무나 널리 퍼져 몇 년 전에 많은 교육 기관의 IT 직원이 모여서 이러한 환경에서 Bonjour 가 더 잘 작동 하도록 Apple에 탄원했습니다 .


질문을 직접 해결하려면 일반적으로 네트워크에서 Airplay 서비스를 확장하기 위해 매우 특수한 구성이 필요합니다. 특정 구성은 현재 무선 솔루션 (Cisco, Aerohive, Ubiquity 등)에 따라 크게 달라집니다. 일반적으로 무선 공급 업체와 Bonjour를 검색하는 경우 최소한 올바른 방향으로 안내하는 문서를 찾아야합니다.

Cisco의 Avahi Bonjour 게이트웨이 솔루션을 성공적으로 배포 한 적이 있으며 꼭 필요한 경우가 아니라면 조사하지 않는 것이 좋습니다.

결론은 세 번째 질문에서 지적한 바와 같이 홈 네트워크 환경을위한 폐쇄적이고 독점적이며 문서화되지 않은 서비스 *이기 때문에 항상 Apple의 자비에 있습니다. 따라서 Apple이 변경하기로 결정하지 않으면 가능한 한 엔터프라이즈 네트워크에서 구현하지 않는 것이 좋습니다.

* mDNSResponder의 기본 코드는 공개적이고 비 독점적이며 Apache 라이센스에 따라 사용 가능합니다. 그러나 Apple의 iDevices 및 MacOS 내부에 대한 Apple의 구현은 모두 귀하가 통제 할 수 없으며 언제든지 변경할 수 있습니다.


이 위대한 답변에 감사드립니다. "특정 구성이 현재 무선 솔루션에 크게 의존 할 것"이라고 말하면 Airplay 서비스가 VLAN 전체에서 작동하도록 서로 다른 기술을 사용하거나 동일한 기술에 대한 양을 구성하기 위해 서로 다른 관리 인터페이스를 가지고 있음을 의미합니까? 전선?
alx9r

2
실제로는 조금입니다. 다른 공급 업체는 Bonjour 멀티 캐스트 패킷의 스누핑 및 재전송을 다르게 처리하며, 다른 공급 업체는 내 경험에 따라 구성 방식이 크게 다릅니다.
Brett Lykins

봉쥬르 게이트웨이 솔루션으로 발견 한 내용에 대해 자세히 알아볼 수 있습니까?
Robert Siemer

4

아바 히 가 도와 드리겠습니다. 이 옵션이 많이 있지만이 해야 서브넷에 걸쳐 트래픽을 얻을. 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".

나는 탁구대를 설정
했다고

3

브로드 캐스트 ( 멀티 캐스트 ) 기술 이기 때문에 작동하지 않습니다 . (또한 Bonjour 참조) 브로드 캐스트 도메인 (예 : VLAN)을 교차하려면 프록시가 필요합니다. 저는 Mac 사용자는 아니지만 이전에 이러한 프록시 설정을 보았습니다. 따라서 iDevice는 무선 및 유선 LAN이 다른 프린터에 연결할 수 있습니다. 사용 된 프로그램은 기억 나지 않지만 무료는 아닙니다.


1
감사합니다. 잘못된 검색어를 사용하고있는 것 같습니다. 에어 플레이 프록시를 검색하면 산출 상당히 포괄적 인 것 어느.
alx9r

기술적으로 멀티 캐스트 기술입니다.
bahamat

@bahamat, true, 그러나 로컬 범위이므로 방송 될 수도 있습니다. 자연스럽게 단일 브로드 캐스트 도메인을 떠나지 않습니다.
Ricky Beam

이것은 네트워크 엔지니어링입니다. 다른 질문하지 마십시오. 브로드 캐스트와 멀티 캐스트 사이에는 큰 차이가 있습니다. 무시할 것이 아닌 네트워크 엔지니어링 전문가를위한 토론 사이트 mDNS는 멀티 캐스트 (따라서 "m")이며 기본적으로 단일 브로드 캐스트 도메인으로 제한됩니다.
bahamat

1

Airplay는 IP를 통해 이동하므로 일반적인 라우팅이 적용됩니다. 한 VLAN에서 다른 VLAN으로 트래픽을 라우팅하려면 라우터가 필요합니다. 그러나 멀티 캐스트를 시작하지 않으면 Bonjour는 로컬 VLAN에 남아 있습니다.

이것은 나쁜 생각입니까? 때에 따라 다르지 ;-). 교육적인 추측을하려면 프로덕션 환경에 대해 더 많은 정보를 제공해야합니다.


0

다른 사람들이 지적했듯이 mDNS / Bonjour 프록시로 작동 할 수있는 Avahi ( http://www.avahi.org ) 라는 무료 오픈 소스 솔루션 이 있습니다. 이 소프트웨어가 실행되는 시스템에는 mDNS 서비스를 알리고 자하는 각 VLAN / 서브넷에 대한 네트워크 인터페이스가 있어야합니다. 그러나 실제 서비스가 작동하려면 VLAN 간 라우팅을 활성화하거나 액세스 목록 또는 방화벽에서 mDNS 가능 장치에 대한 TCP / UDP 연결을 허용해야합니다. 다른 옵션으로는 mDNS 프록시 역할을 할 수있는 Cisco 또는 Ubiquiti wifi 컨트롤러가 있습니다. 또는 Mac을 사용하는 경우 각 서비스에 대한 프록시를 만들 수 있습니다 ( https://kb.acronis.com/sites/default/files/content/2013/ 01 / 39490 / wanbonjour_1.pdf). 이 마지막 솔루션의 문제점은 각 개별 서비스에 대한 프록시를 작성해야하며 시스템을 재부팅 할 때마다 다시 실행해야한다는 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.