Chromecast a DLNA: objavovanie nikdy neprekročí routovaný VPN

Tlačidlo odosielania nič nezobrazuje, VLC DLNA zostáva prázdne a stroj na druhom konci odpovedá na ping bez sťažnosti. Táto kombinácia nie je problém šírky pásma ani záhada firewallu. Objavovanie v týchto protokoloch je skupinová výmena v lokálnom segmente a routovaný tunel neprenáša prevádzku adresovanú skupine. Relácia, ktorú sa snažíte spustiť, sa nikdy neponúkne.

Dostupnosť je v poriadku. Objavovanie chýba.

Mýtus: tunel potrebuje nastavenie alebo viac kapacity

Zvyčajné rady sú zapnúť prevádzku peer-to-peer, zvýšiť MTU alebo zmeniť typ zariadenia tunela. Ani jedna nepridá broadcastovú doménu. Multicast doručujú prepínače a miestny sieťový zásobník a point-to-point rozhranie TUN nemá žiadnu skupinovú adresu, ktorú by zaplavilo.

Zmena nastavení môže zlyhanie zosilniť. Nedokáže však privodiť oznámenie tam, kde ho protokol nikdy neposlal.

Čo je výmena objavovania v skutočnosti

Tri vzory pokrývajú takmer všetko, s čím sa stretnete. mDNS posiela na 224.0.0.251 cez UDP 5353, SSDP posiela na 239.255.255.250 cez UDP 1900 a staršie zoznamy prehliadania SMB chodili na broadcastovú adresu podsiete. Každá je adresovaná skupine, nie hostiteľovi, a každá očakáva poslucháča v tom istom segmente. Príjemca za routovaným tunelom v tom segmente nie je, takže nič nedorazí.

Aj preposlané oznámenie nesie užitočné zaťaženie: zvyčajne LAN adresu a port odosielateľa, na ktoré sa vzdialený divák potom musí dostať.

Prečítajte si zachytávanie, kým zmeníte tunel

Zachytávajte na rozhraní tunela, kým aplikácia skenuje. Prázdne zachytávanie znamená, že oznámenie nikdy neprekročilo hranicu, a žiadne ladenie tunela to nezmení. Pakety, ktoré sa predsa objavia, kým aplikácia stále nič neukazuje, zvyčajne znamenajú, že inzerovaná adresa je z pohľadu diváka nedostupná, čo je problém routovania v kostýme objavovania.

Dve minúty zachytávania nahradia hodinu hádania o portoch: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tri opravy, najlacnejšia prvá

Nasmerujte klienta priamo na adresu služby. Pri DLNA, SMB a obyčajných mediálnych serveroch to objavovanie úplne preskočí a preukáže, že cesta užitočného zaťaženia funguje, čo z toho robí najlepší prvý test aj použiteľné obídenie. Chromecast je výnimka, pretože prijímač očakáva, že bude nájdený, nie adresovaný.

Preposielajte protokol na bráne. Reflector mDNS opakuje oznámenia medzi tunelom a LAN a Avahi dodáva sekciu reflectora, ktorá preberá explicitný zoznam rozhraní. Držte preposielanie úzke a potvrďte, že inzerovaná adresa je dostupná z oboch strán, inak odpoveď stále ukazuje na podsieť, do ktorej divák nevie routovať.

Most namiesto routovania. Segment TAP, kde server premostí zariadenie tap do LAN, umiestni oba konce do jednej broadcastovej domény, takže oznámenia prechádzajú bez zmeny. Je to aj najdrahšia možnosť, pretože jedna podsieť znamená jednu doménu zlyhania a každá multicastová služba v LAN teraz dosiahne každého partnera.

Čo nepomôže, nech sa to odporúča akokoľvek často

Prepnutie dev tun na dev tap bez mosta zanechá zariadenie TAP, ktoré je stále routované, takže správanie sa nemení. client-to-client povoľuje peer-to-peer unicast a nezaplavuje broadcasty. Presmerovanie portu objavovania na jedného hostiteľa nedoručí prevádzku adresovanú skupine. Mediálny server viazaný na jednu adresu odpovedá ďalej na tej adrese, kým jeho vlastná konfigurácia neuvedie rozhranie VPN.

Otestujte jednu priamu unicast požiadavku a potom jednu ohlásenú požiadavku. Ak prvá funguje a druhá nie, tunel je zdravý a celý problém je v objavovaní.