Chromecast- en DLNA-detectie steekt nooit een gerouteerde VPN over

De castknop toont niets, VLC DLNA blijft leeg, en de machine aan de andere kant antwoordt zonder klagen op ping. Die combinatie is geen bandbreedteprobleem en geen firewallraadsel. Detectie in deze protocollen is een groepsuitwisseling op het lokale segment, en een gerouteerde tunnel vervoert geen groepsgeadresseerd verkeer. De sessie die u probeert te starten wordt nooit aangeboden.

De bereikbaarheid is in orde. De detectie ontbreekt.

De mythe: de tunnel heeft een instelling of meer capaciteit nodig

De gebruikelijke suggesties zijn peer-to-peerverkeer inschakelen, de MTU verhogen of het apparaattype van de tunnel wijzigen. Geen ervan voegt een broadcastdomein toe. Multicast wordt geleverd door switches en door de lokale netwerkstack, en een punt-tot-punt TUN-interface heeft geen groepsadres om te overspoelen.

Instellingen wijzigen kan de fout luidruchtiger maken. Het kan een aankondiging niet laten verschijnen waar het protocol er nooit een heeft gestuurd.

Wat de detectie-uitwisseling werkelijk is

Drie patronen dekken bijna alles wat u tegenkomt. mDNS stuurt naar 224.0.0.251 op UDP 5353, SSDP stuurt naar 239.255.255.250 op UDP 1900, en oudere SMB-browselijsten gingen naar het broadcastadres van het subnet. Elk is geadresseerd aan een groep en niet aan een host, en elk verwacht een luisteraar op hetzelfde segment. Een ontvanger aan de andere kant van een gerouteerde tunnel zit niet op dat segment, dus er komt niets aan.

Zelfs een doorgestuurde aankondiging draagt een payload: meestal het LAN-adres en de poort van de afzender, die de externe kijker dan moet kunnen bereiken.

Lees een opname voordat u de tunnel wijzigt

Leg vast op de tunnelinterface terwijl de app scant. Een lege opname betekent dat de aankondiging de grens nooit heeft overschreden, en geen enkele tunnelafstelling verandert dat. Pakketten die toch verschijnen terwijl de app nog niets toont, betekenen meestal dat het aangekondigde adres niet bereikbaar is vanaf de kijker, wat een routeringsprobleem in detectiekostuum is.

Twee minuten opname vervangen een uur gissen naar poorten: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Drie oplossingen, de goedkoopste eerst

Wijs de client rechtstreeks naar het serviceadres. Voor DLNA, SMB en eenvoudige mediaservers slaat dit detectie volledig over en bewijst het dat het payloadpad werkt, wat het de beste eerste test en tegelijk een bruikbare omweg maakt. Chromecast is de uitzondering, omdat de ontvanger verwacht gevonden te worden in plaats van geadresseerd.

Stuur het protocol door bij de gateway. Een mDNS-reflector herhaalt aankondigingen tussen de tunnel en het LAN, en Avahi levert een reflectorsectie die een expliciete interfacelijst aanneemt. Houd de doorsturing smal, en bevestig dat het aangekondigde adres van beide kanten bereikbaar is, anders wijst het antwoord nog steeds naar een subnet waar de kijker niet naartoe kan routeren.

Bridg in plaats van routeren. Een TAP-segment waarbij de server het tap-apparaat op het LAN bridget, zet beide uiteinden in één broadcastdomein, zodat aankondigingen ongewijzigd oversteken. Het is ook de duurste optie, want één subnet betekent één storingsdomein en elke multicastdienst op het LAN bereikt nu elke peer.

Wat niet helpt, hoe vaak het ook wordt voorgesteld

De overstap van dev tun naar dev tap zonder bridge laat een TAP-apparaat achter dat nog steeds gerouteerd wordt, dus het gedrag verandert niet. client-to-client staat peer-to-peerunicast toe en overspoelt geen broadcasts. Een detectiepoort naar één host doorsturen levert geen groepsgeadresseerd verkeer. Een mediaserver die aan één adres is gebonden, blijft op dat adres antwoorden tot de eigen configuratie de VPN-interface vermeldt.

Test één rechtstreeks unicastverzoek en daarna één aangekondigd verzoek. Als het eerste werkt en het tweede niet, is de tunnel gezond en is detectie het hele probleem.