Chromecast i DLNA otkrivanje nikada ne prelazi rutirani VPN

Dugme za emitovanje ne prikazuje ništa, VLC DLNA ostaje prazan, a mašina na drugoj strani odgovara na ping bez žalbe. Ta kombinacija nije problem propusnog opsega niti misterija zaštitnog zida. Otkrivanje u ovim protokolima je grupna razmjena na lokalnom segmentu, i rutirani tunel ne prenosi saobraćaj s grupnim adresama. Sesija koju pokušavate pokrenuti nikada se ne nudi.

Dostupnost je u redu. Otkrivanje nedostaje.

Mit: tunelu treba postavka ili više kapaciteta

Uobičajeni prijedlozi su omogućiti peer-to-peer saobraćaj, podići MTU ili promijeniti tip uređaja tunela. Nijedan od njih ne dodaje broadcast domenu. Multicast dostavljaju preklopnici i lokalni mrežni stek, a point-to-point TUN interfejs nema grupnu adresu koju bi preplavio.

Promjena postavki može učiniti kvar glasnijim. Ne može učiniti da se najava pojavi tamo gdje je protokol nikada nije poslao.

Šta je zapravo razmjena otkrivanja

Tri obrasca pokrivaju gotovo sve što ćete sresti. mDNS šalje na 224.0.0.251 preko UDP 5353, SSDP šalje na 239.255.255.250 preko UDP 1900, a starije SMB liste pregledanja išle su na broadcast adresu podmreže. Svaka je adresirana na grupu, a ne na host, i svaka očekuje slušaoca na istom segmentu. Prijemnik s druge strane rutiranog tunela nije na tom segmentu, pa ništa ne stiže.

Čak i proslijeđena najava nosi korisni teret: obično LAN adresu i port pošiljaoca, do kojih udaljeni gledalac tada mora moći doći.

Pročitajte snimak prije nego što promijenite tunel

Snimajte na interfejsu tunela dok aplikacija skenira. Prazan snimak znači da najava nikada nije prešla granicu, i nikakvo podešavanje tunela to ne mijenja. Paketi koji se ipak pojave dok aplikacija još ne pokazuje ništa obično znače da je oglašena adresa nedostupna s gledaočeve strane, što je problem rutiranja u kostimu otkrivanja.

Dvije minute snimka zamjenjuju sat nagađanja o portovima: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tri rješenja, najjeftinije prvo

Uputite klijenta direktno na adresu usluge. Za DLNA, SMB i obične medijske servere to potpuno preskače otkrivanje i dokazuje da put korisnog tereta radi, što ga čini najboljim prvim testom i upotrebljivim zaobilaznim rješenjem. Chromecast je izuzetak, jer prijemnik očekuje da bude pronađen, a ne adresiran.

Proslijedite protokol na gatewayu. mDNS reflektor ponavlja najave između tunela i LAN-a, a Avahi dolazi s odjeljkom reflektora koji prima eksplicitnu listu interfejsa. Držite prosljeđivanje uskim i potvrdite da je oglašena adresa dostupna s obje strane, inače odgovor još uvijek pokazuje na podmrežu do koje gledalac ne može rutirati.

Premostite umjesto rutiranja. TAP segment u kojem server premošćuje tap uređaj na LAN stavlja oba kraja u jednu broadcast domenu, pa najave prolaze nepromijenjene. To je i najskuplja opcija, jer jedna podmreža znači jednu domenu kvara i svaka multicast usluga na LAN-u sada doseže svakog peera.

Šta ne pomaže, koliko god se često predlagalo

Prebacivanje dev tun na dev tap bez mosta ostavlja TAP uređaj koji je još rutiran, pa se ponašanje ne mijenja. client-to-client dozvoljava peer-to-peer unicast i ne preplavljuje broadcast. Prosljeđivanje porta za otkrivanje na jedan host ne dostavlja saobraćaj s grupnim adresama. Medijski server vezan na jednu adresu nastavlja odgovarati na toj adresi dok njegova vlastita konfiguracija ne navede VPN interfejs.

Testirajte jedan direktan unicast zahtjev, pa jedan oglašeni zahtjev. Ako prvi radi, a drugi ne, tunel je zdrav i otkrivanje je cijeli problem.