Обнаружение 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-запрос, затем один объявленный запрос. Если первый работает, а второй нет, туннель здоров и обнаружение — вся проблема.