Chromecast a DLNA: objevování nikdy nepřekročí routovaný VPN

Tlačítko odesílání nic nezobrazuje, VLC DLNA zůstává prázdné a stroj na druhém konci odpovídá na ping bez stížnosti. Tahle kombinace není problém šířky pásma ani záhada firewallu. Objevování v těchto protokolech je skupinová výměna v lokálním segmentu a routovaný tunel nenese provoz adresovaný skupině. Relace, kterou se snažíte spustit, se nikdy nenabídne.

Dostupnost je v pořádku. Objevování chybí.

Mýtus: tunel potřebuje nastavení nebo víc kapacity

Obvyklé rady jsou zapnout provoz peer-to-peer, zvýšit MTU nebo změnit typ zařízení tunelu. Ani jedna nepřidá broadcastovou doménu. Multicast doručují přepínače a místní síťový stack a point-to-point rozhraní TUN nemá žádnou skupinovou adresu, kterou by zaplavilo.

Změna nastavení může selhání zesílit. Nedokáže ale přivodit oznámení tam, kde ho protokol nikdy neposlal.

Co je výměna objevování ve skutečnosti

Tři vzory pokrývají téměř vše, s čím se setkáte. mDNS posílá na 224.0.0.251 přes UDP 5353, SSDP posílá na 239.255.255.250 přes UDP 1900 a starší seznamy prohlížení SMB chodily na broadcastovou adresu podsítě. Každá je adresovaná skupině, nikoli hostiteli, a každá očekává posluchače ve stejném segmentu. Příjemce za routovaným tunelem v tom segmentu není, takže nic nedorazí.

I přeposlané oznámení nese užitečné zatížení: obvykle LAN adresu a port odesílatele, na které se vzdálený divák pak musí dostat.

Přečtěte si zachytávání, než změníte tunel

Zachytávejte na rozhraní tunelu, zatímco aplikace skenuje. Prázdné zachytávání znamená, že oznámení nikdy nepřekročilo hranici, a žádné ladění tunelu to nezmění. Pakety, které se přesto objeví, zatímco aplikace stále nic neukazuje, obvykle znamenají, že inzerovaná adresa je z pohledu diváka nedostupná, což je problém routování v kostýmu objevování.

Dvě minuty zachytávání nahradí hodinu hádání o portech: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tři opravy, nejlevnější první

Namiřte klienta přímo na adresu služby. U DLNA, SMB a obyčejných mediálních serverů to objevování úplně přeskočí a prokáže, že cesta užitečného zatížení funguje, což z toho dělá nejlepší první test i použitelné obejití. Chromecast je výjimka, protože přijímač očekává, že bude nalezen, ne adresován.

Přeposílejte protokol na bráně. Reflector mDNS opakuje oznámení mezi tunelem a LAN a Avahi dodává sekci reflectoru, která bere explicitní seznam rozhraní. Držte přeposílání úzké a potvrďte, že inzerovaná adresa je dostupná z obou stran, jinak odpověď stále ukazuje na podsíť, do které divák neumí routovat.

Bridge místo routování. Segment TAP, kde server přemostí zařízení tap do LAN, staví oba konce do jedné broadcastové domény, takže oznámení procházejí beze změny. Je to také nejdražší možnost, protože jedna podsíť znamená jednu doménu selhání a každá multicastová služba v LAN teď dosáhne na každého peer.

Co nepomůže, ať se to doporučuje jakkoli často

Přepnutí dev tun na dev tap bez bridge zanechá zařízení TAP, které je stále routované, takže se chování nemění. client-to-client povoluje peer-to-peer unicast a nezaplavuje broadcast. Přesměrování portu pro objevování na jeden hostitel nedoručí provoz adresovaný skupině. Mediální server svázaný s jednou adresou odpovídá dál na této adrese, dokud jeho vlastní konfigurace neuvede rozhraní VPN.

Otestujte jeden přímý unicast požadavek a pak jeden ohlášený požadavek. Pokud první funguje a druhý ne, tunel je zdravý a celý problém je v objevování.