Откривање Chromecast-а и DLNA никада не прелази рутирани VPN

Дугме за емитовање не приказује ништа, VLC DLNA остаје празан, а машина на другој страни одговара на ping без жалбе. Та комбинација није проблем пропусног опсега нити мистерија заштитног зида. Откривање је у тим протоколима групна размена на локалном сегменту, и рутирани тунел не преноси саобраћај са групним адресама. Сесија коју покушавате да покренете никада се не нуди.

Доступност је у реду. Откривање недостаје.

Мит: тунелу треба поставка или више капацитета

Уобичајени предлози су омогућити peer-to-peer саобраћај, подићи MTU или променити тип уређаја тунела. Ниједан од њих не додаје broadcast домен. Multicast достављају прекидачи и локални мрежни стек, а point-to-point TUN интерфејс нема групну адресу коју би препоплавио.

Промена поставки може учинити квар гласнијим. Не може учинити да се најава појави тамо где је протокол никада није послао.

Шта је заправо размена откривања

Три обрасца покривају готово све што ћете срести. mDNS шаље на 224.0.0.251 преко UDP 5353, SSDP шаље на 239.255.255.250 преко UDP 1900, а старије SMB листе прегледања ишле су на broadcast адресу подмреже. Свака је адресирана на групу, а не на хост, и свака очекује слушаоца на истом сегменту. Пријемник са друге стране рутираног тунела није на том сегменту, па ништа не стиже.

Чак и прослеђена најава носи корисни терет: обично LAN адресу и порт пошиљаоца, до којих удаљени гледалац тада мора моћи да дође.

Прочитајте снимак пре него што промените тунел

Снимајте на интерфејсу тунела док апликација скенира. Празан снимак значи да најава никада није прешла границу, и никакво подешавање тунела то не мења. Пакети који се ипак појаве док апликација још не показује ништа обично значе да је оглашена адреса недоступна са гледаочеве стране, што је проблем рутирања у костиму откривања.

Два минута снимка замењују сат нагађања о портовима: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Три решења, најјефтиније прво

Упутите клијента директно на адресу услуге. За DLNA, SMB и обичне медијске сервере то потпуно прескаче откривање и доказује да пут корисног терета ради, што га чини најбољим првим тестом и употребљивим заобилазним решењем. Chromecast је изузетак, јер пријемник очекује да буде пронађен, а не адресиран.

Прослеђујте протокол на gateway-у. mDNS рефлектор понавља најаве између тунела и LAN-а, а Avahi долази са одељком рефлектора који прима експлицитну листу интерфејса. Држите прослеђивање уским и потврдите да је оглашена адреса доступна са обе стране, иначе одговор још увек показује на подмрежу до које гледалац не може да рутира.

Премостите уместо рутирања. TAP сегмент у коме сервер премошћује tap уређај на LAN ставља оба краја у један broadcast домен, па најаве пролазе непромењене. То је и најскупља опција, јер једна подмрежа значи један домен квара и свака multicast услуга на LAN-у сада достиже сваког пера.

Шта не помаже, колико год се често предлагало

Пребацивање dev tun на dev tap без моста оставља TAP уређај који је још рутиран, па се понашање не мења. client-to-client дозвољава peer-to-peer unicast и не преплављује broadcast. Прослеђивање порта за откривање на један хост не доставља саобраћај са групним адресама. Медијски сервер везан за једну адресу наставља да одговара на тој адреси док његова сопствена конфигурација не наведе VPN интерфејс.

Тестирајте један директан unicast захтев, па један оглашени захтев. Ако први ради, а други не, тунел је здрав и откривање је цео проблем.