Chromecast и DLNA откривањето никогаш не преминува рутиран VPN

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

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

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

Вообичаените предлози се да се овозможи peer-to-peer сообраќај, да се покачи 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 барање, потоа едно објавено барање. Ако првото работи, а второто не, тунелот е здрав и откривањето е целиот проблем.