Odkrivanje Chromecast in DLNA nikoli ne prečka usmerjenega VPN

Gumb za predvajanje ne prikaže ničesar, VLC DLNA ostane prazen, stroj na drugi strani pa odgovori na ping brez pritožbe. Ta kombinacija ni težava s pasovno širino in ne uganka požarnega zidu. Odkrivanje v teh protokolih je skupinska izmenjava v lokalnem segmentu, in usmerjeni tunel ne prenaša prometa s skupinskimi naslovi. Seja, ki jo poskušate začeti, ni nikoli ponujena.

Dosegljivost je v redu. Odkrivanje manjka.

Mit: tunel potrebuje nastavitev ali več zmogljivosti

Običajni predlogi so omogočiti promet med enakovrednimi vozlišči, dvigniti MTU ali spremeniti vrsto naprave tunela. Nobeden od njih ne doda domene oddajanja. Multicast dostavljajo stikala in lokalni omrežni sklad, vmesnik TUN od točke do točke pa nima skupinskega naslova, ki bi ga lahko preplavil.

Spreminjanje nastavitev lahko okvaro naredi glasnejšo. Ne more pa povzročiti, da bi se obvestilo pojavilo tam, kamor ga protokol ni nikoli poslal.

Kaj je izmenjava odkrivanja v resnici

Trije vzorci pokrijejo skoraj vse, kar boste srečali. mDNS pošilja na 224.0.0.251 prek UDP 5353, SSDP pošilja na 239.255.255.250 prek UDP 1900, starejši seznami brskanja SMB pa so šli na naslov oddajanja podomrežja. Vsak je naslovljen na skupino in ne na gostitelja, in vsak pričakuje poslušalca v istem segmentu. Prejemnik na drugi strani usmerjenega tunela ni v tem segmentu, zato nič ne prispe.

Tudi posredovano obvestilo nosi koristno obremenitev: običajno naslov LAN in vrata pošiljatelja, ki jim mora oddaljeni gledalec nato priti do konca.

Preberite zajem, preden spremenite tunel

Zajemajte na vmesniku tunela, medtem ko aplikacija skenira. Prazen zajem pomeni, da obvestilo ni nikoli prestopilo meje, in nobeno uglaševanje tunela tega ne spremeni. Paketi, ki se vseeno pojavijo, medtem ko aplikacija še vedno ne prikazuje ničesar, običajno pomenijo, da je oglašeni naslov z vidika gledalca nedosegljiv, kar je usmerjevalna težava v preobleki odkrivanja.

Dve minuti zajema nadomestita uro ugibanja o vratih: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tri rešitve, najcenejša prva

Usmerite odjemalca neposredno na naslov storitve. Za DLNA, SMB in preproste medijske strežnike to popolnoma preskoči odkrivanje in dokaže, da pot koristne obremenitve deluje, zato je to najboljši prvi preizkus in tudi uporabna obhodna rešitev. Chromecast je izjema, ker sprejemnik pričakuje, da ga bodo našli, ne naslovili.

Posredujte protokol na prehodu. Odsevnik mDNS ponavlja obvestila med tunelom in LAN, Avahi pa prinaša razdelek odsevnika, ki sprejme izrecen seznam vmesnikov. Posredovanje naj bo ozko, in potrdite, da je oglašeni naslov dosegljiv z obeh strani, sicer odgovor še vedno kaže na podomrežje, v katero gledalec ne more usmerjati.

Mostite namesto usmerjajte. Segment TAP, kjer strežnik premosti napravo tap v LAN, postavi oba konca v eno domeno oddajanja, zato obvestila prehajajo nespremenjena. To je tudi najdražja možnost, ker eno podomrežje pomeni eno domeno okvare in vsaka storitev multicast v LAN zdaj doseže vsakega enakovrednega partnerja.

Kaj ne pomaga, pa naj se predlaga še tako pogosto

Preklop z dev tun na dev tap brez mostu pusti napravo TAP, ki je še vedno usmerjena, zato se vedenje ne spremeni. client-to-client dovoljuje unicast med enakovrednimi partnerji in ne preplavlja oddajanj. Posredovanje vrat odkrivanja na enega gostitelja ne dostavi prometa s skupinskimi naslovi. Medijski strežnik, vezan na en naslov, še naprej odgovarja na tem naslovu, dokler njegova konfiguracija ne navede vmesnika VPN.

Preskusite eno neposredno zahtevo unicast, nato eno oglašeno zahtevo. Če prva deluje in druga ne, je tunel zdrav in odkrivanje je cela težava.