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 заявка, после една обявена заявка. Ако първата работи, а втората не, тунелът е здрав и откриването е целият проблем.