Chromecast- och DLNA-upptäckt korsar aldrig en routad VPN

Cast-knappen visar ingenting, VLC DLNA förblir tomt, och maskinen i andra änden svarar på ping utan klagomål. Den kombinationen är inte ett bandbreddsproblem och inte en brandväggsgåta. Upptäckt i dessa protokoll är ett grupputbyte på det lokala segmentet, och en routad tunnel bär inte gruppadresserad trafik. Sessionen du försöker starta erbjuds aldrig.

Nåbarheten är okej. Upptäckten saknas.

Myten: tunneln behöver en inställning eller mer kapacitet

De vanliga förslagen är att aktivera peer-to-peer-trafik, höja MTU:n eller ändra tunnelns enhetstyp. Ingen av dem lägger till en broadcast-domän. Multicast levereras av switchar och av den lokala nätverksstacken, och ett punkt-till-punkt TUN-gränssnitt har ingen gruppadress att översvämma.

Ändrade inställningar kan göra felet mer högljutt. Det kan inte få en annonsering att dyka upp där protokollet aldrig skickade någon.

Vad upptäcktsutbytet egentligen är

Tre mönster täcker nästan allt du möter. mDNS skickar till 224.0.0.251 på UDP 5353, SSDP skickar till 239.255.255.250 på UDP 1900, och äldre SMB-bläddringslistor gick till subnätets broadcast-adress. Var och en är adresserad till en grupp och inte till en värd, och var och en förväntar sig en lyssnare på samma segment. En mottagare på andra sidan en routad tunnel är inte på det segmentet, så ingenting anländer.

Även en vidarebefordrad annonsering bär en nyttolast: vanligtvis avsändarens LAN-adress och port, som den avlägsna tittaren sedan måste kunna nå.

Läs en inspelning innan du ändrar tunneln

Spela in på tunnelgränssnittet medan appen skannar. En tom inspelning betyder att annonseringen aldrig korsade gränsen, och ingen tunneljustering ändrar det. Paket som ändå dyker upp medan appen fortfarande inte visar något betyder vanligtvis att den annonserade adressen inte går att nå från tittaren, vilket är ett routningsproblem i upptäcktskostym.

Två minuters inspelning ersätter en timmes gissningar om portar: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tre lösningar, den billigaste först

Peka klienten direkt mot tjänstadressen. För DLNA, SMB och enkla medieservrar hoppar detta helt över upptäckten och bevisar att nyttolastvägen fungerar, vilket gör det till det bästa första testet och samtidigt en användbar omväg. Chromecast är undantaget, eftersom mottagaren förväntar sig att bli hittad och inte adresserad.

Vidarebefordra protokollet vid gatewayen. En mDNS-reflektor upprepar annonseringar mellan tunneln och LAN:et, och Avahi levererar en reflektorsdel som tar en explicit gränssnittslista. Håll vidarebefordran smal, och bekräfta att den annonserade adressen går att nå från båda sidor, annars pekar svaret fortfarande mot ett subnät som tittaren inte kan routa till.

Brygga i stället för att routa. Ett TAP-segment där servern bryggar tap-enheten över till LAN:et sätter båda ändar i en enda broadcast-domän, så annonseringar passerar oförändrade. Det är också det dyraste alternativet, eftersom ett subnät innebär en feldomän och varje multicast-tjänst på LAN:et når nu varje peer.

Vad som inte hjälper, hur ofta det än föreslås

Bytet från dev tun till dev tap utan en brygga lämnar en TAP-enhet som fortfarande routas, så beteendet ändras inte. client-to-client tillåter peer-to-peer-unicast och översvämmar inte broadcast. Att vidarebefordra en upptäcktsport till en enda värd levererar inte gruppadresserad trafik. En medieserver bunden till en adress fortsätter svara på den adressen tills dess egen konfiguration listar VPN-gränssnittet.

Testa en direkt unicast-förfrågan, sedan en annonserad förfrågan. Om den första fungerar och den andra inte är tunneln frisk och upptäckten är hela problemet.