Chromecast- og DLNA-oppdaging kryssar aldri ein ruta VPN

Cast-knappen viser ingenting, VLC DLNA blir verande tom, og maskina i andre enden svarar på ping utan klager. Den kombinasjonen er ikkje eit bandbreiddeproblem eller ei brannmur-gåte. Oppdaging i desse protokollane er ei gruppeutveksling på det lokale segmentet, og ein ruta tunnel ber ikkje gruppeadressert trafikk. Økta du prøver å starte vert aldri tilboden.

Nåbarheita er fin. Oppdaginga manglar.

Myten: tunnelen treng ei innstilling eller meir kapasitet

Dei vanlege forslaga er å aktivere peer-to-peer-trafikk, heve MTU-en eller endre einheitstypen til tunnelen. Ingen av dei legg til eit kringkastingsdomene. Multicast vert levert av svitsjar og av den lokale nettverksstakken, og eit punkt-til-punkt TUN-grensesnitt har inga gruppeadresse å oversvømme.

Endra innstillingar kan gjere feilen meir høglytt. Dei kan ikkje få ei annonsering til å dukke opp der protokollen aldri sende ei.

Kva oppdagingsutvekslinga eigentleg er

Tre mønster dekkjer 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-blaingslister gjekk til kringkastingsadressa til subnettet. Kvar av dei er adressert til ei gruppe og ikkje til ein vert, og kvar ventar ein lyttar på same segment. Ein mottakar på den andre sida av ein ruta tunnel er ikkje på det segmentet, så ingenting kjem fram.

Jamvel ei vidaresend annonsering ber ei nyttelast: vanlegvis LAN-adressa og porten til sendaren, som den fjerne sjåaren då må kunne nå.

Les eit opptak før du endrar tunnelen

Ta opp på tunnelgrensesnittet medan appen skannar. Eit tomt opptak betyr at annonseringa aldri kryssa grensa, og inga mengd tunelljustering endrar det. Pakkar som likevel dukkar opp medan appen framleis ikkje viser noko, betyr vanlegvis at den annonserte adressa ikkje kan nåast frå sjåaren, noko som er eit ruteproblem i oppdagingskostyme.

To minutt med opptak erstattar ein times gjetting om portar: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tre løysingar, den billegaste først

Pek klienten direkte mot tenesteadressa. For DLNA, SMB og enkle medieservarar hoppar dette heilt over oppdaginga og beviser at nyttelastbana virkar, noko som gjer det til den beste første testen og òg ein brukbar omveg. Chromecast er unntaket, fordi mottakaren ventar å bli funnen og ikkje adressert.

Vidaresend protokollen ved gatewayen. Ein mDNS-reflektor gientar annonseringar mellom tunnelen og LAN-et, og Avahi leverer ein reflektordel som tek ei eksplisitt grensesnittliste. Hald vidaresendinga smal, og stadfest at den annonserte adressa kan nåast frå begge sider, elles peikar svaret framleis på eit subnett sjåaren ikkje kan rute til.

Bru i staden for å rute. Eit TAP-segment der tenaren bruar tap-eininga over på LAN-et, set begge endar i eitt kringkastingsdomene, slik at annonseringar kryssar uendra. Det er òg det dyraste alternativet, fordi eitt subnett betyr eitt feildomene og kvar multicast-teneste på LAN-et når no kvar peer.

Kva som ikkje hjelper, uansett kor ofte det vert føreslege

Å bytte dev tun til dev tap utan ei bru etterlèt ei TAP-eining som framleis vert ruta, så åtferda endrar seg ikkje. client-to-client tillèt peer-to-peer-unicast og oversvømmer ikkje kringkasting. Å vidaresende ein oppdagingsport til ein vert leverer ikkje gruppeadressert trafikk. Ein medieserver bunden til éi adresse held fram med å svare på den adressa til hans eigen konfigurasjon listar opp VPN-grensesnittet.

Test éin direkte unicast-førespurnad, deretter éin annonsert førespurnad. Viss den første virkar og den andre ikkje, er tunnelen sunn og oppdaginga er heile problemet.