Chromecast og DLNA-opdagelse krydser aldrig en routed VPN

Cast-knappen viser intet, VLC DLNA forbliver tom, og maskinen i den anden ende svarer på ping uden klager. Den kombination er ikke et båndbreddeproblem eller en firewall-gåde. Opdagelse i disse protokoller er en gruppeudveksling på det lokale segment, og en routed tunnel bærer ikke gruppeadresseret trafik. Den session, du prøver at starte, bliver aldrig tilbudt.

Nåbarheden er fin. Opdagelsen mangler.

Myten: tunnelen kræver en indstilling eller mere kapacitet

De sædvanlige forslag er at aktivere peer-to-peer-trafik, hæve MTU'en eller ændre tunnelens enhedstype. Ingen af dem tilføjer et broadcast-domæne. Multicast leveres af switches og af den lokale netværksstak, og en punkt-til-punkt TUN-grænseflade har ingen gruppeadresse at oversvømme.

Ændrede indstillinger kan gøre fejlen mere højlydt. De kan ikke få en annoncering til at dukke op, hvor protokollen aldrig sendte en.

Hvad opdagelsesudvekslingen egentlig er

Tre mønstre dækker næsten alt, hvad du møder. mDNS sender til 224.0.0.251 på UDP 5353, SSDP sender til 239.255.255.250 på UDP 1900, og ældre SMB-browselister gik til undernettets broadcast-adresse. Hver af dem er adresseret til en gruppe frem for til en vært, og hver forventer en lytter på samme segment. En modtager på den anden side af en routed tunnel er ikke på det segment, så intet ankommer.

Selv en videresendt annoncering bærer en nyttelast: normalt afsenderens LAN-adresse og port, som den fjerne seer derefter skal kunne nå.

Læs en optagelse, før du ændrer tunnelen

Optag på tunnelgrænsefladen, mens appen scanner. En tom optagelse betyder, at annonceringen aldrig krydsede grænsen, og ingen mængde tunetuning ændrer det. Pakker, der faktisk dukker op, mens appen stadig ikke viser noget, betyder normalt, at den annoncerede adresse ikke kan nås fra seeren, hvilket er et routingproblem i opdagelseskostume.

To minutters optagelse erstatter en times gætteri om porte: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tre løsninger, den billigste først

Peg klienten direkte mod tjenesteadressen. For DLNA, SMB og almindelige medieservere springer det opdagelsen helt over og beviser, at nyttelaststien virker, hvilket gør det både til den bedste første test og en brugbar omvej. Chromecast er undtagelsen, fordi modtageren forventer at blive fundet frem for adresseret.

Videresend protokollen ved gatewayen. En mDNS-reflektor gentager annonceringer mellem tunnelen og LAN'et, og Avahi leverer et reflektorafsnit, der tager en eksplicit grænsefladeliste. Hold videresendelsen smal, og bekræft, at den annoncerede adresse kan nås fra begge sider, ellers peger svaret stadig på et undernet, som seeren ikke kan route til.

Bridg i stedet for at route. Et TAP-segment, hvor serveren bridger tap-enheden over på LAN'et, sætter begge ender i ét broadcast-domæne, så annonceringer krydser uændret. Det er også den dyreste mulighed, fordi ét undernet betyder ét fejldomæne, og hver multicast-tjeneste på LAN'et når nu hver peer.

Hvad ikke hjælper, uanset hvor ofte det foreslås

At skifte dev tun til dev tap uden en bro efterlader en TAP-enhed, der stadig routes, så adfærden ændrer sig ikke. client-to-client tillader peer-to-peer-unicast og oversvømmer ikke broadcasts. At videresende en opdagelsesport til én vært leverer ikke gruppeadresseret trafik. En medieserver bundet til én adresse bliver ved med at svare på den adresse, indtil dens egen konfiguration angiver VPN-grænsefladen.

Test én direkte unicast-anmodning, derefter én annonceret anmodning. Hvis den første virker, og den anden ikke, er tunnelen sund, og opdagelsen er hele problemet.