Виявлення 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-запит, потім один оголошений запит. Якщо перший працює, а другий ні, тунель здоровий і виявлення — уся проблема.