Chromecast와 DLNA 검색은 라우팅된 VPN을 결코 넘지 않는다

캐스트 버튼에는 아무것도 나오지 않고, VLC DLNA는 비어 있으며, 반대편 기계는 불평 없이 ping에 응답합니다. 이 조합은 대역폭 문제도, 방화벽의 수수께끼도 아닙니다. 이 프로토콜에서 검색은 로컬 세그먼트의 그룹 교환이며, 라우팅된 터널은 그룹 주소 트래픽을 전달하지 않습니다. 시작하려는 세션은 결코 제공되지 않습니다.

도달성은 괜찮습니다. 검색이 빠진 것입니다.

속설: 터널에 설정이나 더 많은 용량이 필요하다

흔한 제안은 피어 투 피어 트래픽을 켜거나, MTU를 올리거나, 터널 장치 유형을 바꾸라는 것입니다. 어느 것도 브로드캐스트 도메인을 추가하지 않습니다. 멀티캐스트는 스위치와 로컬 네트워크 스택이 전달하며, 점대점 TUN 인터페이스에는 넘칠 그룹 주소가 없습니다.

설정을 바꾸면 실패가 더 요란해질 뿐입니다. 프로토콜이 한 번도 보내지 않은 광고를 그 자리에 나타나게 할 수는 없습니다.

검색 교환이란 실제로 무엇인가

마주칠 거의 모든 경우를 세 가지 패턴이 덮습니다. mDNS는 UDP 5353으로 224.0.0.251에 보내고, SSDP는 UDP 1900으로 239.255.255.250에 보내며, 오래된 SMB 탐색 목록은 서브넷 브로드캐스트 주소로 갔습니다. 각각은 호스트가 아니라 그룹을 향하고, 각각은 같은 세그먼트의 수신자를 기대합니다. 라우팅된 터널 건너편의 수신자는 그 세그먼트에 없으므로 아무것도 도착하지 않습니다.

중계된 광고조차 페이로드를 나릅니다. 보통 송신자의 LAN 주소와 포트이며, 원격 시청자가 그곳에 도달할 수 있어야 합니다.

터널을 바꾸기 전에 캡처를 읽으세요

앱이 스캔하는 동안 터널 인터페이스에서 캡처하세요. 빈 캡처는 광고가 경계를 넘지 않았다는 뜻이며, 어떤 터널 조정도 이를 바꾸지 못합니다. 앱이 여전히 아무것도 보여주지 않는데 패킷이 나타난다면 보통 광고된 주소가 시청자에게서 도달 불가능하다는 뜻이며, 이는 검색 옷을 입은 라우팅 문제입니다.

몇 분의 캡처가 포트에 대한 한 시간의 추측을 대신합니다: tcpdump -ni tun0 udp port 5353 or udp port 1900.

세 가지 해결책, 가장 싼 것부터

클라이언트를 서비스 주소로 직접 지정하세요. DLNA, SMB, 단순 미디어 서버에서는 검색을 완전히 건너뛰고 페이로드 경로가 작동함을 증명하므로, 최고의 첫 시험이자 쓸 만한 우회책이 됩니다. Chromecast는 예외인데, 수신자는 주소 지정되기보다 발견되기를 기대합니다.

게이트웨이에서 프로토콜을 중계하세요. mDNS 반사기는 터널과 LAN 사이에서 광고를 반복하며, Avahi는 명시적 인터페이스 목록을 받는 반사기 섹션을 제공합니다. 중계를 좁게 유지하고, 광고된 주소가 양쪽에서 도달 가능한지 확인하세요. 그렇지 않으면 응답은 여전히 시청자가 라우팅할 수 없는 서브넷을 가리킵니다.

라우팅 대신 브리지하세요. 서버가 tap 장치를 LAN에 브리지하는 TAP 세그먼트는 양쪽 끝을 하나의 브로드캐스트 도메인에 두므로 광고가 그대로 통과합니다. 가장 비싼 선택이기도 한데, 서브넷 하나는 장애 도메인 하나를 뜻하고 LAN의 모든 멀티캐스트 서비스가 이제 모든 피어에 도달합니다.

도움이 되지 않는 것, 아무리 자주 권해도

브리지 없이 dev tun에서 dev tap로 바꿔도 여전히 라우팅되는 TAP 장치가 남으므로 동작은 바뀌지 않습니다. client-to-client는 피어 간 유니캐스트를 허용하고 브로드캐스트를 넘치게 하지 않습니다. 검색 포트를 한 호스트로 전달해도 그룹 주소 트래픽은 전달되지 않습니다. 한 주소에 묶인 미디어 서버는 자체 구성이 VPN 인터페이스를 나열할 때까지 그 주소에서 계속 응답합니다.

직접 유니캐스트 요청 하나를 시험하고, 다음으로 광고된 요청 하나를 시험하세요. 첫 번째가 되고 두 번째가 안 되면 터널은 건강하고 검색이 문제의 전부입니다.