Chromecast i DLNA otkrivanje nikad ne prelazi rutiranim VPN-om

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 je u tim protokolima grupna razmena na lokalnom segmentu, i rutirani tunel ne prenosi saobraćaj sa grupnim adresama. Sesija koju pokušavate da pokrenete nikada se ne nudi.

Dostupnost je u redu. Otkrivanje nedostaje.

Mit: tunelu treba postavka ili više kapaciteta

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

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

Šta je zapravo razmena 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 sa druge strane rutiranog tunela nije na tom segmentu, pa ništa ne stiže.

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

Pročitajte snimak pre nego što promenite 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 menja. Paketi koji se ipak pojave dok aplikacija još ne pokazuje ništa obično znače da je oglašena adresa nedostupna sa gledaočeve strane, što je problem rutiranja u kostimu otkrivanja.

Dva minuta snimka zamenjuju sat nagađanja o portovima: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tri reš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 rešenjem. Chromecast je izuzetak, jer prijemnik očekuje da bude pronađen, a ne adresiran.

Prosleđujte protokol na gatewayu. mDNS reflektor ponavlja najave između tunela i LAN-a, a Avahi dolazi sa odeljkom reflektora koji prima eksplicitnu listu interfejsa. Držite prosleđivanje uskim i potvrdite da je oglašena adresa dostupna sa obe strane, inače odgovor još uvek pokazuje na podmrežu do koje gledalac ne može da rutira.

Premostite umesto rutiranja. TAP segment u kome server premošćuje tap uređaj na LAN stavlja oba kraja u jedan broadcast domen, pa najave prolaze nepromenjene. To je i najskuplja opcija, jer jedna podmreža znači jedan domen 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 menja. client-to-client dozvoljava peer-to-peer unicast i ne preplavljuje broadcast. Prosleđivanje porta za otkrivanje na jedan host ne dostavlja saobraćaj sa grupnim adresama. Medijski server vezan za jednu adresu nastavlja da odgovara na toj adresi dok njegova sopstvena konfiguracija ne navede VPN interfejs.

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