Chromecast- og DLNA-oppdagelse krysser aldri en rutet VPN

Cast-knappen viser ingenting, VLC DLNA forblir tom, og maskinen i andre enden svarer på ping uten klager. Den kombinasjonen er ikke 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 prøver å starte blir aldri tilbudt.

Nåbarheten er fin. Oppdagelsen mangler.

Myten: tunnelen trenger en innstilling eller mer kapasitet

De vanlige forslagene er å aktivere peer-to-peer-trafikk, heve MTU-en eller endre enhetstypen til 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 en.

Hva oppdagelsesutvekslingen egentlig er

Tre mønstre dekker nesten alt du møter. 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 fjerne seeren deretter må kunne nå.

Les en opptak før du endrer tunnelen

Ta opp på tunnelgrensesnittet mens appen skanner. Et tomt opptak betyr at annonseringen aldri krysset grensen, og ingen mengde tunelljustering endrer det. Pakker som likevel dukker opp mens appen fortsatt ikke viser noe, betyr vanligvis at den annonserte adressen ikke kan nås 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 direkte mot tjenesteadressen. For DLNA, SMB og enkle medieservere hopper dette helt over oppdagelsen og beviser at nyttelastbanen virker, noe som gjør det til den beste første testen og også 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 en eksplisitt grensesnittliste. Hold videresendingen smal, og bekreft at den annonserte adressen kan nås fra begge sider, ellers peker svaret fortsatt på et subnett seeren ikke kan rute til.

Bro i stedet for å rute. Et TAP-segment der serveren broer tap-enheten over på 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år nå 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 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.