Casting stoppt über ein VPN: Erkennung, Steuerung oder Stream?

Casting bricht an drei Stellen, die vom Sofa aus gleich aussehen. Das Telefon sieht den Empfänger vielleicht nie, der Empfänger erscheint und lehnt dann die Sitzung ab, oder die Sitzung beginnt und stockt eine Minute später. Ein Tunnel auf dem Telefon verändert jeden dieser Wege anders, und bei einem davon ändert er gar nichts. Benennen Sie zuerst die scheiternde Stufe und entscheiden Sie dann, ob eine Richtlinienänderung überhaupt der richtige Hebel ist.

Benennen Sie die scheiternde Stufe, bevor Sie die Richtlinie ändern

Beobachten Sie, was das Telefon unmittelbar nach dem Tippen auf das Cast-Symbol tut. Eine leere Liste ist ein Erkennungsergebnis, ein Tipp, der einen Fehler meldet, ist ein Steuerungsergebnis, und eine Sitzung, die vor dem Stocken beginnt, ist ein Wiedergabeergebnis. Diese drei haben verschiedene Zuständigkeiten, und normalerweise betreffen nur die ersten beiden die Tunneleinstellungen des Telefons.

Schreiben Sie die Stufe auf, bevor Sie etwas ändern. Eine Korrektur an der falschen Stufe macht den nächsten Test unlesbar, und der meiste Casting-Aberglaube stammt genau aus dieser Verwechslung.

Erkennung ist lokaler Verkehr, und ein Tunnel versteckt ihn

Empfänger kündigen sich über lokale Ankündigungen an, und das Telefon findet sie mit Abfragen auf demselben Link, also entfernt alles, was das Telefon von diesem Link entfernt, auch den Empfänger aus der Liste. Ein Tunnel, der den gesamten Verkehr vom LAN wegleitet, kann diese Austausche verbergen, und eine lokale Netzwerkberechtigung auf App-Ebene kann sie blockieren, selbst wenn die Route existiert. Gast-Wi-Fi mit Client-Isolation erzeugt dieselbe leere Liste ganz ohne VPN. Beweisen Sie, dass beide Geräte ein Segment teilen, bevor Sie den Tunnel beschuldigen.

avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR

Der erste Befehl listet, was sich im Segment des Hilfsrechners ankündigt, und der zweite fragt die Multicast-DNS-Gruppe direkt. Ein Empfänger, der in beiden fehlt, erscheint auch in einer Telefon-App nicht, unabhängig vom Tunnelzustand des Telefons. Ist der Empfänger von einem Gerät mit ausgeschaltetem Tunnel sichtbar und von einem mit eingeschaltetem unsichtbar, haben Sie Stufe und Ursache zugleich gefunden.

Eine LAN-Ausnahme hält den Tunnel aktiv

Viele Clients bieten eine Lokalnetz-Ausnahme, die den Tunnel aktiv lässt und lokale Adressen zulässt. Nutzen Sie diese dokumentierte Einstellung, statt den Kill Switch oder die ganze Firewall abzuschalten, denn diese ändern weit mehr, als Casting braucht. Trennt das Netz intelligente Geräte absichtlich, bitten Sie den Eigentümer um den konkreten Erkennungs-, Steuerungs- und Rückverkehr statt um pauschalen Zugang.

nc -vz 192.168.1.50 8009

Ein Steuerungstest gegen den Empfänger trennt Berechtigung von Erreichbarkeit: Ein Port, der antwortet, heißt, der Weg existiert, während eine Ablehnung heißt, dass das Telefon das Gerät erkennen durfte und trotzdem nicht mit ihm sprechen kann. Die Ports 8008 und 8009 sind die üblichen Cast-Ports, und eine App kann andere nutzen, also ist ein einzelner abgelehnter Port ein Hinweis und kein Urteil. Ausnahme und App-Berechtigung bleiben unabhängig, denn lokaler Zugang schafft keine Route, und eine Route gewährt keine Berechtigung. Ein Kill Switch kann nach einem Neuverbinden auch lokalen Verkehr verwerfen, weshalb die Erkennung erneut getestet werden muss, sobald der Tunnel zurück ist.

Die Wiedergabe nutzt vielleicht nicht die Verbindung des Telefons

Bei einer app-gesteuerten Sitzung übergibt das Telefon dem Empfänger eine Medienadresse, und der Empfänger lädt sie über seine eigene Verbindung, also ändert eine andere öffentliche Adresse des Telefons für den Stream nichts. Ein kontogebundener Titel kann trotzdem aus eigenen Gründen scheitern, und Googles Casting-Anforderungen decken App- und Gerätekompatibilität ab, nicht den Netzwerkweg. Den Fernseher selbst durch einen Tunnel zu leiten, ist eine eigene Konfiguration mit eigenen Richtlinienfragen.

Zwei Hinweise unterscheiden die Modi. Ein Cast, der das Sperren des Telefonbildschirms übersteht, ist app-gesteuert, weil der Empfänger selbst lädt; ein Spiegel, der stoppt, wenn der Bildschirm des Senders gesperrt wird, ist ein fortlaufender Stream vom Telefon. Wenn Erkennung und Steuerung gelingen, die Wiedergabe aber stockt, schauen Sie stattdessen auf die Wi-Fi-Verbindung des Empfängers und seinen Internetweg, denn ein Geschwindigkeitstest auf dem Telefon beschreibt das Telefon und nicht den Fernseher.

Machen Sie die Ausnahme rückgängig und testen Sie erneut

Jede vorübergehende Änderung braucht einen Rückweg, und die Reihenfolge zählt. Entfernen Sie die LAN-Ausnahme, verbinden Sie den Tunnel neu, damit der Client seine Richtlinie erneut anwendet, wiederholen Sie dann den Erkennungsschritt und notieren Sie, ob der Empfänger wieder verschwindet. Diese Reihenfolge sagt Ihnen, ob die Ausnahme die Arbeit tat oder ob sich dazwischen etwas anderes geändert hat.

# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'

Prüfen Sie danach die drei Stufen getrennt, denn ein Erfolg bei einer sagt nichts über die anderen. Prüfen Sie dann, ob unbeteiligte Telefon-Apps noch der vorgesehenen Route folgen, denn eine lokale Ausnahme, die still zu einer vollständigen Umgehung wurde, ist ein schlechteres Ergebnis als ein Cast, der einen zusätzlichen Tipp braucht.