Chromecast і DLNA: выяўленне ніколі не перасякае маршрутызаваны VPN

Кнопка трансляцыі нічога не паказвае, VLC DLNA застаецца пустым, а машына на іншым канцы адказвае на ping без скаргаў. Такая камбінацыя — не праблема прапускной здольнасці і не загадка брандмаўэра. Выяўленне ў гэтых пратаколах — гэта групавы абмен у лакальным сегменце, і маршрутызаваны тунель не нясе трафік з групавымі адрасамі. Сеанс, які вы спрабуеце пачаць, ніколі не прапануецца.

Дасяжнасць у парадку. Выяўлення няма.

Міф: тунелю патрэбна налада або большая прапускная здольнасць

Звычайныя парады — уключыць трафік паміж аднаранговымі вузламі, павялічыць MTU або змяніць тып прылады тунеля. Ні адна з іх не дадае шырокавяшчальны дамен. Multicast дастаўляюць камутатары і лакальны сеткавы стек, а кропка-кропкавы інтэрфейс TUN не мае групавога адраса, які можна заліць.

Змена налад можа зрабіць збой гучнейшым. Яна не можа прымусіць аб'яву з'явіцца там, дзе пратакол яе ніколі не дасылаў.

Што такое абмен выяўлення насамрэч

Тры ўзоры ахопліваюць амаль усё, што вы сустрэнеце. mDNS дасылае на 224.0.0.251 праз UDP 5353, SSDP дасылае на 239.255.255.250 праз UDP 1900, а старыя спісы агляду SMB ішлі на адрас шырокавяшчальнай рассылкі падсеткі. Кожны адрасаваны групе, а не вузлу, і кожны чакае слухача ў тым жа сегменце. Прыёмнік за маршрутызаваным тунелем не ў гэтым сегменце, таму нічога не прыходзіць.

Нават перададзеная аб'ява нясе карысную нагрузку: звычайна LAN-адрас і порт адпраўніка, да якіх аддалены глядач павінен тады дабрацца.

Прачытайце перахоп перад зменай тунеля

Рабіце перахоп на інтэрфейсе тунеля, пакуль праграма сканіруе. Пусты перахоп азначае, што аб'ява ніколі не перасякла мяжу, і ніякая настройка тунеля гэтага не зменіць. Пакеты, якія ўсё ж з'яўляюцца, пакуль праграма па-ранейшаму нічога не паказвае, звычайна азначаюць, што абвешчаны адрас недасяжны для гледача — гэта праблема маршрутызацыі ў касцюме выяўлення.

Дзве хвіліны перахопу замяняюць гадзіну здагадак пра порты: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Тры рашэнні, самае таннае першым

Направіце кліент непасрэдна на адрас службы. Для DLNA, SMB і звычайных медыясервераў гэта цалкам абынае выяўленне і даказвае, што шлях карыснай нагрузкі працуе, што робіць яго і лепшым першым тэстам, і працоўным абыходам. Chromecast — выключэнне, бо прыёмнік чакае, што яго знойдуць, а не адрасуюць.

Перадавайце пратакол на шлюзе. Рэфлектар mDNS паўтарае аб'явы паміж тунелем і LAN, а Avahi пастаўляецца з раздзелам рэфлектара, які прымае яўны спіс інтэрфейсаў. Трымайце перадачу вузкай і пераканайцеся, што абвешчаны адрас дасяжны з абодвух бакоў, інакш адказ па-ранейшаму паказвае на падсетку, да якой глядач не можа маршрутызаваць.

Майструйце мост замест маршрутызацыі. Сегмент TAP, дзе сервер мастуе прыладу tap у LAN, змяшчае абодва канцы ў адзін шырокавяшчальны дамен, таму аб'явы праходзяць без змен. Гэта таксама самы дарагі варыянт, бо адна падсетка — адзін дамен адмовы, і кожная служба multicast у LAN цяпер дасягае кожнага вузла.

Што не дапамагае, як бы часта гэта ні прапаноўвалі

Пераключэнне dev tun на dev tap без моста пакідае прыладу TAP, якая ўсё яшчэ маршрутызуецца, таму паводзіны не змяняюцца. client-to-client дазваляе аднаранговы unicast і не залівае шырокавяшчальныя рассылкі. Перасылка порта выяўлення на адзін вузел не дастаўляе трафік з групавымі адрасамі. Медыясервер, прывязаны да аднаго адраса, працягвае адказваць на гэтым адрасе, пакуль яго ўласная канфігурацыя не ўнясе інтэрфейс VPN.

Праверце адзін прамы unicast-запыт, затым адзін абвешчаны запыт. Калі першы працуе, а другі не, тунель здаровы, і ўся праблема ў выяўленні.