Chromecast- en DLNA-ontdekking steek nooit 'n gerouteerde VPN oor nie

Die cast-knoppie lys niks, VLC se DLNA bly leeg, en die masjien aan die ander kant antwoord ping sonder klagte. Daardie kombinasie is nie 'n bandwydteprobleem of 'n firewall-raaisel nie. Ontdekking in hierdie protokolle is 'n groepuitruiling op die plaaslike segment, en 'n gerouteerde tonnel dra nie groepgeadresseerde verkeer nie. Die sessie wat jy probeer begin, word nooit aangebied nie.

Bereikbaarheid is reg. Ontdekking ontbreek.

Die mite: die tonnel het 'n instelling of meer kapasiteit nodig

Die gewone voorstelle is om eweknie-verkeer te aktiveer, die MTU te verhoog of die tipe tonneltoestel te verander. Nie een daarvan voeg 'n uitsaai-domein by nie. Multicast word deur skakelaars en deur die plaaslike netwerkstapel afgelewer, en 'n punt-tot-punt TUN-koppelvlak het geen groepsadres om te oorstroom nie.

Instellings verander kan die mislukking harder maak. Dit kan nie 'n aankondiging laat verskyn waar die protokol nooit een gestuur het nie.

Wat die ontdekkingsuitruiling werklik is

Drie patrone dek byna alles wat jy sal teekom. mDNS stuur na 224.0.0.251 op UDP 5353, SSDP stuur na 239.255.255.250 op UDP 1900, en ouer SMB-blaailyse het na die subnet se uitsaaiadres gegaan. Elkeen word aan 'n groep eerder as aan 'n gasheer geadresseer, en elkeen verwag 'n luisteraar op dieselfde segment. 'n Ontvanger oor 'n gerouteerde tonnel is nie op daardie segment nie, so niks kom aan nie.

Selfs 'n deurgegewe aankondiging dra 'n loonvrag: gewoonlik die sender se LAN-adres en poort, wat die afgeleë kyker dan moet kan bereik.

Lees 'n opname voordat jy die tonnel verander

Maak 'n opname op die tonnelkoppelvlak terwyl die app skandeer. 'n Leë opname beteken die aankondiging het nooit die grens oorgesteek nie, en geen mate van tonnelverstelling verander dit nie. Pakkette wat wel verskyn terwyl die app steeds niks wys, beteken gewoonlik die geadverteerde adres is onbereikbaar vanaf die kyker, wat 'n routeringsprobleem in 'n ontdekkingskostuum is.

Twee minute se opname vervang 'n uur se raai oor poorte: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Drie oplossings, die goedkoopste eerste

Wys die kliënt direk na die diensadres. Vir DLNA, SMB en gewone mediabediensers slaan dit ontdekking heeltemal oor en bewys dit dat die loonvragpad werk, wat dit die beste eerste toets sowel as 'n bruikbare oplossing maak. Chromecast is die uitsondering, want die ontvanger verwag om gevind te word eerder as geadresseer.

Herleid die protokol by die poort. 'n mDNS-reflektor herhaal aankondigings tussen die tonnel en die LAN, en Avahi lewer 'n reflektor-afdeling wat 'n eksplisiete koppelvlaklys neem. Hou die herleiding smal, en bevestig die geadverteerde adres is van beide kante bereikbaar, of die antwoord wys steeds na 'n subnet waarheen die kyker nie kan roeteer nie.

Brug eerder as roeteer. 'n TAP-segment waar die bediener die tap-toestel op die LAN brug, plaas beide kante in een uitsaai-domein, so aankondigings steek onveranderd oor. Dit is ook die duurste opsie, want een subnet beteken een foutdomein en elke multicast-diens op die LAN bereik nou elke eweknie.

Wat nie help nie, hoe dikwels dit ook voorgestel word

Om dev tun na dev tap te skakel sonder 'n brug laat 'n TAP-toestel wat steeds gerouteer word, so gedrag verander nie. client-to-client laat eweknie-eenrigtingverkeer toe en oorstroom nie uitsaaiings nie. Om 'n ontdekkingspoort na een gasheer te stuur, lewer nie groepgeadresseerde verkeer nie. 'n Mediabediener wat aan een adres gebind is, bly op daardie adres antwoord totdat sy eie konfigurasie die VPN-koppelvlak lys.

Toets een direkte eenrigtingversoek, dan een aangekondigde versoek. As die eerste werk en die tweede nie, is die tonnel gesond en is ontdekking die hele probleem.