Chromecast i DLNA otkrivanje nikada ne prelazi rutiranim VPN-om

Gumb za emitiranje ne prikazuje ništa, VLC DLNA ostaje prazan, a stroj na drugoj strani odgovara na ping bez pritužbe. Ta kombinacija nije problem propusnosti niti misterij vatrozida. Otkrivanje je u tim protokolima grupna razmjena na lokalnom segmentu, i rutirani tunel ne prenosi promet 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 su prijedlozi omogućiti peer-to-peer promet, podići MTU ili promijeniti vrstu uređaja tunela. Nijedan od njih ne dodaje broadcast domenu. Multicast dostavljaju preklopnici i lokalni mrežni stog, a point-to-point TUN sučelje nema grupnu adresu koju bi preplavilo.

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

Što je zapravo razmjena otkrivanja

Tri obrasca pokrivaju gotovo sve što ćete susresti. mDNS šalje na 224.0.0.251 preko UDP 5353, SSDP šalje na 239.255.255.250 preko UDP 1900, a stariji SMB popisi pregledavanja išli su na broadcast adresu podmreže. Svaka je adresirana na grupu, a ne na host, i svaka očekuje slušatelja na istom segmentu. Prijamnik 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šiljatelja, do kojih udaljeni gledatelj tada mora moći doći.

Pročitajte snimku prije nego što promijenite tunel

Snimajte na sučelju tunela dok aplikacija skenira. Prazna snimka 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 gledateljeve strane, što je problem rutiranja u kostimu otkrivanja.

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

Tri rješenja, najjeftinije prvo

Uputite klijenta izravno na adresu usluge. Za DLNA, SMB i obične medijske poslužitelje 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 iznimka, jer prijamnik očekuje da bude pronađen, a ne adresiran.

Proslijedite protokol na pristupniku. mDNS reflektor ponavlja najave između tunela i LAN-a, a Avahi dolazi s odjeljkom reflektora koji prima eksplicitan popis sučelja. 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 gledatelj ne može rutirati.

Premostite umjesto rutiranja. TAP segment u kojem poslužitelj 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.

Što 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 dopušta peer-to-peer unicast i ne preplavljuje broadcast. Prosljeđivanje porta za otkrivanje na jedan host ne dostavlja promet s grupnim adresama. Medijski poslužitelj vezan na jednu adresu nastavlja odgovarati na toj adresi dok njegova vlastita konfiguracija ne navede VPN sučelje.

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