Die Cast-Schaltfläche listet nichts, VLC DLNA bleibt leer, und die Maschine am anderen Ende antwortet ohne Beschwerde auf Ping. Diese Kombination ist kein Bandbreitenproblem und kein Firewall-Rätsel. Die Erkennung in diesen Protokollen ist ein Gruppenaustausch im lokalen Segment, und ein gerouteter Tunnel transportiert keine gruppenadressierten Daten. Die Sitzung, die Sie starten möchten, wird nie angeboten.

Die Erreichbarkeit stimmt. Die Erkennung fehlt.

Der Mythos: Der Tunnel braucht eine Einstellung oder mehr Kapazität

Die üblichen Vorschläge sind, Peer-to-Peer-Verkehr zu aktivieren, die MTU zu erhöhen oder den Gerätetyp des Tunnels zu ändern. Keiner davon fügt eine Broadcast-Domäne hinzu. Multicast wird von Switches und vom lokalen Netzwerk-Stack zugestellt, und eine Punkt-zu-Punkt-TUN-Schnittstelle hat keine Gruppenadresse, die sie fluten könnte.

Geänderte Einstellungen können den Fehler lauter machen. Sie können eine Ankündigung nicht dort erscheinen lassen, wo das Protokoll nie eine gesendet hat.

Was der Erkennungsaustausch wirklich ist

Drei Muster decken fast alles ab, was Ihnen begegnet. mDNS sendet an 224.0.0.251 über UDP 5353, SSDP sendet an 239.255.255.250 über UDP 1900, und ältere SMB-Browselisten gingen an die Broadcast-Adresse des Subnetzes. Jede ist an eine Gruppe statt an einen Host adressiert, und jede erwartet einen Zuhörer im selben Segment. Ein Empfänger jenseits eines gerouteten Tunnels ist nicht in diesem Segment, also kommt nichts an.

Selbst eine weitergeleitete Ankündigung trägt eine Nutzlast: meist die LAN-Adresse und den Port des Absenders, die der entfernte Betrachter dann erreichen können muss.

Lesen Sie einen Mitschnitt, bevor Sie den Tunnel ändern

Schneiden Sie an der Tunnelschnittstelle mit, während die App scannt. Ein leerer Mitschnitt bedeutet, dass die Ankündigung die Grenze nie überquert hat, und kein Tunen des Tunnels ändert das. Pakete, die doch auftauchen, während die App weiterhin nichts zeigt, bedeuten meist, dass die angekündigte Adresse vom Betrachter aus nicht erreichbar ist – ein Routingproblem im Erkennungskostüm.

Zwei Minuten Mitschnitt ersetzen eine Stunde Raten über Ports: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Drei Lösungen, die billigste zuerst

Richten Sie den Client direkt auf die Dienstadresse. Bei DLNA, SMB und einfachen Medienservern überspringt das die Erkennung vollständig und beweist, dass der Nutzlastpfad funktioniert, was es zum besten ersten Test und zugleich zu einer brauchbaren Umgehung macht. Chromecast ist die Ausnahme, weil der Empfänger erwartet, gefunden statt adressiert zu werden.

Leiten Sie das Protokoll am Gateway weiter. Ein mDNS-Reflektor wiederholt Ankündigungen zwischen Tunnel und LAN, und Avahi bringt einen Reflektor-Abschnitt mit, der eine ausdrückliche Schnittstellenliste annimmt. Halten Sie die Weiterleitung eng, und bestätigen Sie, dass die angekündigte Adresse von beiden Seiten erreichbar ist, sonst zeigt die Antwort weiterhin auf ein Subnetz, in das der Betrachter nicht routen kann.

Bridgen statt routen. Ein TAP-Segment, bei dem der Server das tap-Gerät in das LAN bridgt, bringt beide Enden in eine Broadcast-Domäne, sodass Ankündigungen unverändert übergehen. Es ist zugleich die teuerste Option, denn ein Subnetz bedeutet eine Fehlerdomäne, und jeder Multicast-Dienst im LAN erreicht jetzt jeden Peer.

Was nicht hilft, so oft es auch vorgeschlagen wird

Der Wechsel von dev tun zu dev tap ohne eine Bridge hinterlässt ein TAP-Gerät, das weiterhin geroutet wird, das Verhalten ändert sich also nicht. client-to-client erlaubt Peer-to-Peer-Unicast und flutet keine Broadcasts. Einen Erkennungsport an einen Host weiterzuleiten, liefert keine gruppenadressierten Daten. Ein Medienserver, der an eine Adresse gebunden ist, antwortet weiter auf dieser Adresse, bis seine eigene Konfiguration die VPN-Schnittstelle aufführt.

Testen Sie eine direkte Unicast-Anfrage, dann eine angekündigte Anfrage. Funktioniert die erste und die zweite nicht, ist der Tunnel gesund, und die Erkennung ist das ganze Problem.

Ähnliche Artikel