Chromecast- og DLNA-oppdagelse krysser aldri en rutet VPN

Cast-knappen viser ingen ting, VLC DLNA forblir tomt, og maskinen i andre enden svarer på ping uten klager. Den kombinasjonen er verken et båndbreddeproblem eller en brannmur-gåte. Oppdagelse i disse protokollene er en gruppeutveksling på det lokale segmentet, og en rutet tunnel bærer ikke gruppeadressert trafikk. Økten du forsøker å starte blir aldri tilbudt.

Nåbarheten er i orden. Oppdagelsen mangler.

Myten: tunnelen trenger en innstilling eller mer kapasitet

De vanlige forslagene er å slå på peer-to-peer-trafikk, øke MTU-en eller endre enhetstypen for tunnelen. Ingen av dem legger til et kringkastingsdomene. Multicast leveres av svitsjer og av den lokale nettverksstakken, og et punkt-til-punkt TUN-grensesnitt har ingen gruppeadresse å oversvømme.

Endrede innstillinger kan gjøre feilen mer høylytt. De kan ikke få en annonsering til å dukke opp der protokollen aldri sendte noen.

Hva oppdagelsesutvekslingen egentlig er

Tre mønstre dekker nesten alt du vil møte. mDNS sender til 224.0.0.251 på UDP 5353, SSDP sender til 239.255.255.250 på UDP 1900, og eldre SMB-browselister gikk til subnettets kringkastingsadresse. Hver av dem er adressert til en gruppe og ikke til en vert, og hver forventer en lytter på samme segment. En mottaker på den andre siden av en rutet tunnel er ikke på det segmentet, så ingenting ankommer.

Selv en videresendt annonsering bærer en nyttelast: vanligvis avsenderens LAN-adresse og port, som den eksterne seeren deretter må kunne nå.

Les et opptak før du endrer tunnelen

Ta opp på tunnelgrensesnittet mens appen skanner. Et tomt opptak betyr at annonseringen aldri krysset grensen, og ingen tunelljustering endrer på det. Pakker som likevel dukker opp mens appen fortsatt ikke viser noe, betyr vanligvis at den annonserte adressen ikke er nåbar fra seeren, noe som er et ruteproblem i oppdagelseskostyme.

To minutters opptak erstatter en times gjetting om porter: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tre løsninger, den billigste først

Pek klienten rett mot tjenesteadressen. For DLNA, SMB og enkle medieservere hopper dette over oppdagelsen helt og beviser at nyttelastbanen virker, noe som gjør det til den beste første testen og samtidig en brukbar omvei. Chromecast er unntaket, fordi mottakeren forventer å bli funnet og ikke adressert.

Videresend protokollen ved gatewayen. En mDNS-reflektor gjentar annonseringer mellom tunnelen og LAN-et, og Avahi leverer en reflektordel som tar imot en eksplisitt grensesnittliste. Hold videresendingen smal, og bekreft at den annonserte adressen er nåbar fra begge sider, ellers peker svaret fortsatt mot et subnett seeren ikke kan rute til.

Bro i stedet for å rute. Et TAP-segment der serveren broer tap-enheten over til LAN-et, setter begge ender i ett kringkastingsdomene, slik at annonseringer krysser uendret. Det er også det dyreste alternativet, fordi ett subnett betyr ett feildomene og hver multicast-tjeneste på LAN-et nå når hver peer.

Hva som ikke hjelper, uansett hvor ofte det foreslås

Å bytte dev tun til dev tap uten en bro etterlater en TAP-enhet som fortsatt rutes, så atferden endres ikke. client-to-client tillater peer-to-peer-unicast og oversvømmer ikke kringkasting. Å videresende en oppdagelsesport til én vert leverer ikke gruppeadressert trafikk. En medieserver bundet til én adresse fortsetter å svare på den adressen helt til dens egen konfigurasjon lister opp VPN-grensesnittet.

Test én direkte unicast-forespørsel, deretter én annonsert forespørsel. Hvis den første virker og den andre ikke, er tunnelen sunn og oppdagelsen er hele problemet.