Warum Casting nicht mehr funktioniert, nachdem du das Router-VPN aktivierst
Die Erkennung läuft über lokales Multicast, während der Fernseher die Medien selbst abruft. Eine Standardrichtlinie kann die LAN-Anfrage abfangen und in den Tunnel schicken.
Casting funktionierte, bevor das Router-VPN aktiviert wurde, und scheitert unmittelbar danach, während normales Surfen auf dem Telefon weiter funktioniert. Beide Tatsachen sind vereinbar, denn Casting ist keine einzelne Verbindung. Das Telefon findet und steuert den Empfänger über das lokale Netz, und der Empfänger ruft die Medien anschließend über seine eigene Verbindung ab.
Zwei Wege, die unterschiedlich scheitern
Der Steuerweg ist lokal. Ein Telefon findet einen Empfänger, indem es das lokale Netz fragt, und öffnet dann eine Steuerverbindung zu der Adresse, die es gelernt hat. Erscheint der Empfänger nie in der Liste, ist der Erkennungsschritt gescheitert, bevor überhaupt Medien angefordert wurden.
Der Medienweg ist nicht zwangsläufig lokal. Viele Empfänger rufen den Stream selbst ab, über ihre eigene Verbindung und mit ihren eigenen Zugangsdaten, sodass die Route des Telefons nicht die Route des Empfängers beschreibt. Ein Telefon, das einen Ausgang zu nutzen scheint, sagt nichts darüber aus, wohin der Verkehr des Fernsehers geht.
Diese Trennung ist der Grund, warum der Fehler seltsam aussieht. Der Tunnel hat die Routingtabelle des Telefons verändert und die des Fernsehers nicht, also muss ein Symptom, das auf einer Seite des Paars auftritt, auf dieser Seite verfolgt werden. Das falsche Gerät zu verfolgen ist der übliche Grund, warum eine Korrektur nichts zu bewirken scheint.
Warum die Erkennung zuerst bricht
Die Erkennung läuft meist über link-lokales Multicast. mDNS sendet an 224.0.0.251 auf UDP-Port 5353, und SSDP sendet an 239.255.255.250 auf UDP-Port 1900. Beide sind konstruktionsbedingt auf ein Link beschränkt, weshalb ein Router sie nicht ohne Hilfe eines Repeaters oder Proxys zwischen Segmenten weiterleitet. Ein geroutetes VPN erweitert keine Multicast-Gruppe, und eine Richtlinienroute kann eine Gruppe, die das Link nie verlassen hat, nicht auf einem anderen erscheinen lassen.
Der erste Fehler hat also nichts mit Verschlüsselung zu tun. Das Multicast des Telefons verlässt die Schnittstelle, auf der es gesendet wurde, der Empfänger liegt in einem Segment, das es nie sieht, und die Geräteliste kommt leer zurück. Eine leere Liste ist kein Beweis dafür, dass der Fernseher den Internetzugang verloren hat.
Isolation erzeugt dasselbe Symptom ohne jedes VPN. Gastnetze und Client-Isolation an Zugangspunkten hindern Geräte gezielt daran, miteinander zu sprechen, und ein Router-VPN über einem isolierten Segment ändert daran nichts. Prüfe die Isolierungseinstellung, bevor du den Tunnel prüfst. Das ist die billigere Antwort und die häufigere.
Die Segmentaufteilung ist die andere Hälfte. Ein zweiter Router, ein Mesh-Knoten in einem anderen Modus oder ein kabelgebundenes Segment hinter einem weiteren NAT bringen den Empfänger jeweils dorthin, wo der Erkennungsverkehr des Telefons nicht hinkommt.
Warum eine Standardrichtlinie eine lokale Anfrage verschlucken kann
Ein Router, der den gesamten Verkehr in einen Tunnel leitet, installiert eine Standardroute auf der Tunnelschnittstelle. Ist das LAN-Präfix nicht von dieser Richtlinie ausgenommen, passt ein Paket an ein zwei Meter entferntes Gerät nun auf die Standardroute, und der Router schickt die Steueranfrage in den Tunnel statt auf den Switch.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
Die Regelreihenfolge entscheidet über das Ergebnis. Richtlinienrouting wertet Regeln in Prioritätsreihenfolge aus, also muss eine Ausnahme für das lokale Präfix vor der Regel stehen, die die Tunnel-Tabelle auswählt. Die Ausnahme nach der Tunnelregel hinzuzufügen hat keine Wirkung, weshalb eine korrekt aussehende Konfiguration LAN-Verkehr trotzdem an einen entfernten Ausgang schicken kann.
Die Reparatur ist eng: erlaube die konkreten lokalen Ziele, die der Casting-Ablauf braucht, und lass den Rest der Isolation in Ruhe. Client-Isolation als ersten Schritt zu entfernen behebt das Symptom, verwirft aber eine Kontrolle, für die das Netz ausgelegt war.
Ein kurzer Blick auf dem Telefon klärt, welcher der beiden Fehler vorliegt. Zeigt die Route zum Empfänger in den Tunnel, ist die Richtlinie das Problem. Zeigt sie ins LAN und die Erkennung scheitert weiterhin, sind Multicast oder Isolation das Problem, und keine Routenänderung hilft.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTeste den Schritt, der sich geändert hat, nicht das Land
Festgehaltene Beobachtungen schlagen wiederholte Experimente. Notiere, ob der Empfänger in der Geräteliste erscheint, ob eine Steueranfrage ihn erreicht und ob die Wiedergabe startet, sobald ein Stream gewählt wird. Jede Antwort nimmt einen Schritt aus dem Verdacht.
Teste dann jeden Schritt direkt, statt Ausgangsstandorte zu wechseln. Ein VPN-Land zu wechseln testet den Medienweg und lässt die Erkennungs- und Steuerschritte unberührt, kann also zufällig zu helfen scheinen, ohne dir etwas beizubringen.
Prüfe auf der Empfängerseite seine eigene Route und seinen eigenen Kontozustand. Ein Fernseher, der Medien über einen anderen Ausgang abruft als das Telefon, ist ein normales Design, und ein Fehler dort ist eine Frage der Netzwerkrichtlinie des Empfängers und nicht des Tunnels am Telefon.
Schreib das Ergebnis als einen Satz darüber auf, welcher Schritt gebrochen ist und was ihn verändert hat. Dieser Satz ist mehr wert als eine Woche Ländertauschen, und er überlebt das nächste Firmware-Update.
Casting ist ein gutes Testbeispiel für eine allgemeine Regel zu Tunneln. Wird einer zu einem Netz hinzugefügt, lautet die erste Frage welche Ziele nie in ihn hätten gelangen dürfen. Die zweite ist, welche davon die Richtlinie trotzdem still akzeptiert hat.