Uppgötvun Chromecast og DLNA fer aldrei yfir beina VPN

Straumunarhnappurinn listar ekkert, VLC DLNA helst tómt, og vélin hinum megin svarar ping án kvartana. Þessi samsetning er ekki bandvíddarvandamál né ráðgáta eldveggs. Uppgötvun í þessum samskiptareglum er hópaskipti á staðbundna hlutnum, og bein göng flytja ekki umferð með hópvistfangi. Lotan sem þú ert að reyna að hefja er aldrei boðin.

Nálgan er í lagi. Uppgötvunina vantar.

Goðsögnin: göngin þurfa stillingu eða meiri afkastagetu

Venjulegu tillögurnar eru að virkja jafningjaumferð, hækka MTU eða breyta gerð gangatækisins. Ekkert þeirra bætir við útvarpssvæði. Multicast er afhent af rofum og af staðbundna netstakkanum, og punkt-til-punkt TUN-tengi hefur ekkert hópfang til að flæða yfir.

Að breyta stillingum getur gert bilunina háværari. Það getur ekki látið tilkynningu birtast þar sem samskiptareglurnar sendu aldrei neina.

Hvað er uppgötvunarskiptið í raun

Þrjú mynstur ná yfir næstum allt sem þú mætir. mDNS sendir á 224.0.0.251 um UDP 5353, SSDP sendir á 239.255.255.250 um UDP 1900, og eldri SMB-vafurlistar fóru á útvarpsfang undirnetsins. Hvert þeirra er beint að hópi frekar en hýsli, og hvert þeirra væntir hlustanda á sama hluta. Móttakandi handan beinna ganga er ekki á þeim hluta, svo ekkert berst.

Jafnvel endursend tilkynning ber farm: venjulega LAN-fang sendandans og gátt, sem fjarskiptir áhorfandinn verður þá að geta náð í.

Lestu upptöku áður en þú breytir göngunum

Takaðu á gangatenginu meðan forritið skannar. Tóm upptaka þýðir að tilkynningin fór aldrei yfir landamærin, og engin stilling ganganna breytir því. Pakkarnir sem birtast samt meðan forritið sýnir enn ekkert þýða venjulega að tilkynnta fangið sé ónálganlegt frá áhorfandanum, sem er beiningarvandamál í uppgötvunarbúningi.

Tvær mínútur af upptöku koma í stað klukkustundar af giskum um gáttir: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Þrjár lagfæringar, ódýrasta fyrst

Beindu biðlarans beint að fangi þjónustunnar. Fyrir DLNA, SMB og einfalda miðlaraþjóna sleppir þetta uppgötvuninni algjörlega og sannar að farleiðin virkar, sem gerir það að bestu fyrstu prófuninni og líka nothæfri tímabundinni lausn. Chromecast er undantekningin, því móttakandinn væntir þess að verða fundinn frekar en að vera beint að.

Endursentu samskiptareglurnar á gáttinni. mDNS-endurspeglari endurtekur tilkynningar milli ganganna og LANsins, og Avahi kemur með endurspeglarhluta sem tekur skýran tengilista. Haltu endursendingunni þröngri og staðfestu að tilkynnta fangið sé nálganlegt frá báðum hliðum, annars bendir svarið enn á undirnet sem áhorfandinn getur ekki beint um.

Brúaðu í stað þess að beina. TAP-hluti þar sem þjónninn brúar tap-tækið á LANið setur báða enda í eitt útvarpssvæði, svo tilkynningarnar fara óbreyttar yfir. Þetta er líka dýrasti kosturinn, því eitt undirnet þýðir eitt bilunarsvæði og hver multicast-þjónusta á LANinu nær nú til hvers jafningja.

Hvað hjálpar ekki, hversu oft sem það er lagt til

Að skipta dev tun út fyrir dev tap án brúar skilur eftir TAP-tæki sem er enn beint, svo hegðunin breytist ekki. client-to-client leyfir jafningja-unicast og flæðir ekki yfir útvarp. Að senda uppgötvunargátt á einn hýsil flytur ekki umferð með hópvistfangi. Miðlaraþjónn sem er bundinn við eitt fang svarar áfram á því fangi þar til eigin stillingar hans telja upp VPN-tengið.

Prófaðu eina beina unicast-beiðni, svo eina tilkynnta beiðni. Ef sú fyrri virkar og seinni ekki, eru göngin heilbrigð og uppgötvunin er allt vandamálið.