Smart-TV im VPN: Warum Casting und DNS getrennt brechen
Leiten Sie den Verkehr des Fernsehers am Router um und behandeln Sie dann Selektor, Resolver, IPv6 und den Casting-Pfad als vier getrennte Prüfungen.
Ihr Fernseher zeigt den ausländischen Katalog, und die Cast-Schaltfläche des Telefons listet ihn nicht mehr. Beide Beschwerden beginnen mit einem Satz, der vier Einstellungen auf vier Routerseiten nennt. Reparieren Sie den Ausgang, und die Erkennung bricht; reparieren Sie die Erkennung, und das nächste Lease gibt den Ausgang an ein anderes Gerät. Die Reihenfolge unten führt vom Selektor bis zum Casting-Pfad.
Wo jede der vier Entscheidungen lebt
Schreiben Sie die vier auf, bevor Sie ein Menü öffnen, denn jede lebt auf einer anderen Seite und scheitert an einer anderen Stelle. Der Selektor wählt, für welchen Client der Tunnel gilt, der Resolver entscheidet, wo Namen beantwortet werden, die Adressfamilie entscheidet, ob IPv6 überhaupt abgedeckt ist, und der lokale Pfad entscheidet, ob Telefon und Fernseher einander noch sehen. Eine Änderung an einer wirkt von der Seite aus, auf der Sie gerade stehen, vollständig. Der Schaden der anderen drei taucht später auf, in einem anderen Menü, als eine andere Beschwerde.
Firmware-Menüs unterscheiden sich, die vier Orte selten. Der Selektor ist eine statische Zuordnung auf dem DHCP-Server plus eine dazu passende Firewall-Regel. Der Resolver sitzt beim DNS-Dienst, wo ein Forwarder-Eintrag oder eine Liste vorgelagerter Server entscheidet, welche Namen der Router beantwortet und wo die Abfragen hinausgehen. Die Familien-Einstellung gehört zur Schnittstelle selbst, wo IPv4 und IPv6 getrennt konfiguriert werden und eine Richtlinie nur die erste abdecken kann. Der lokale Pfad ist ein Access-Point-Schalter, entweder Client-Isolation oder ein Gästenetz mit eigener Firewall.
Lassen Sie den Selektor das Lease überleben
Sowohl eine Richtlinie pro Gerät als auch ein eigenes Segment funktionieren, und die bessere Wahl ist die, die die Firmware pflegen kann, ohne dass ein zweiter Mensch sie sich merkt. Die Falle ist eine Regel, die an eine Adresse gebunden ist, die der DHCP-Server nach seinem eigenen Zeitplan vergeben hat: Sie funktioniert, bis das Lease wandert, und leitet dann einen Laptop aus Gründen durch ein anderes Land, die sein Besitzer nicht sehen kann. Beständigkeit, nicht Ordnungsliebe, ist die Eigenschaft, die es zu optimieren gilt.
| Rule names the TV by | After the next lease | What it costs |
|---|---|---|
| whatever address it has now | may point at another client | silent misrouting weeks later |
| a reserved address | holds, if the reservation ships with it | one more entry to keep in step |
| a hardware address | holds, unless the device rotates it | privacy features can break it |
| a whole segment | holds for every device on it | neighbours inherit the exit |
Versenden Sie Reservierung und Regel als eine Änderung, denn eine Regel, die ihre Reservierung überlebt, zielt auf fremde Hardware. Eine Regel für ein ganzes Segment ist der haltbarste und der gröbste Selektor, da jedes Gerät hinter dieser Schnittstelle den Ausgang erbt, ob es einen brauchte oder nicht. Welchen Selektor Sie auch wählen, als Nächstes kommt die Abdeckungsfrage: Eine reine IPv4-Richtlinie ist eine halbe Entscheidung, und die nicht abgedeckte Familie ist die, die unbemerkt hinausgeht.
Finden Sie heraus, welchen Resolver der Fernseher wirklich nutzt
Öffnen Sie die eigenen Netzwerkeinstellungen des Fernsehers, bevor Sie den Router anfassen, denn das Gerät entscheidet diesen Streit. Ein auf manuell gesetztes DNS-Feld nutzt weiter diesen Server, was auch immer DHCP anbietet, und eine Set-Top-Box, die einmal für eine andere Region konfiguriert wurde, kann noch auf eine Adresse zeigen, die nicht mehr antwortet. Ist das Feld automatisch, entscheidet die DHCP-Option des Routers, und der eigene Resolver des Routers wird zur nächsten Frage. So oder so steht die Antwort auf dem Bildschirm des Geräts, nicht im Firmware-Handbuch.
Auf der Routerseite ist die Unterscheidung, auf die es ankommt, die zwischen Namen, die der Router selbst beantwortet, und Namen, die er weiterleitet, weil diese beiden Pfade über verschiedene Schnittstellen hinausgehen können. Eine korrekt aufgelöste Abfrage sagt daher nichts darüber, wohin eine Medienanfrage geht, und auf einem Linux-Gateway beantworten die Richtlinientabelle plus ein einziger Routen-Lookup beide Fragen, ohne etwas am Fernseher mitzuschneiden:
ip rule show
ip route get 203.0.113.10Lesen Sie den ersten Befehl für die Regel, die den Verkehr des Fernsehers markiert, und den zweiten für die Schnittstelle, die ein Paket an die Beispieladresse tatsächlich nutzen würde. Wenn die beiden uneins sind, ist nicht der Resolver schuld, sondern die Richtlinie. Ändern Sie eine Sache, und führen Sie das Paar dann erneut aus, denn eine Regelliste ist ordnungsempfindlich, und ein neuer Eintrag kann die Regel überschatten, die den Verkehr trug. Das Ziel ist für Dokumentation reserviert, daher liest sich eine eingefügte Ausgabe wie ein Beispiel.
Casting bricht bei der Erkennung, nicht beim Stream
Casting besteht aus mindestens drei Gesprächen, und nur eines davon trägt Video. Das Telefon entdeckt den Fernseher per Multicast oder Broadcast im lokalen Segment, öffnet einen Steuerkanal, um zu sagen, was abgespielt werden soll, und dann holt der Fernseher den Stream entweder selbst oder empfängt ihn vom Telefon weitergeleitet. Erkennung überquert nie einen Router, der diesen Verkehr nicht weiterleitet, und so kann ein Fernseher genau wie beabsichtigt geroutet werden und trotzdem nie in der Cast-Liste auftauchen.
Gästenetze und Client-Isolation sind die übliche Ursache, und beide tun genau das, wofür sie konfiguriert wurden. Die Isolation im gesamten Funknetz abzuschalten, damit ein Gerät wieder auftaucht, ist die übliche Überkorrektur, und sie öffnet jeden Telefon-zu-Telefon-Pfad wieder, den die Einstellung schließen sollte. Es gibt engere Antworten: eine Pass-Regel für Erkennungs- und Steuerverkehr zwischen zwei Adressen, eine eigene SSID für die Fernseher oder eine dokumentierte Ausnahme im Gästenetz.
Testen Sie das Casting, während die Isolationsregel noch greift, fügen Sie dann nur die Erkennungsausnahme hinzu und testen Sie erneut. Findet der zweite Versuch den Fernseher, ist die Ausnahme die Lösung, und der Rest des Segments kann bleiben, wie er war.
Stoppen Sie den Tunnel und beobachten Sie, in welche Richtung er scheitert
Die letzte Prüfung ist die, die die meisten Setups überspringen: Nehmen Sie den Tunnel herunter und beobachten Sie, ob der Fernseher stoppt oder still über die lokale Verbindung hinausgeht. Eine Richtlinie, die eine Präferenz ausdrückt, scheitert offen, und dieses Scheitern ist leicht zu übersehen, weil die Wiedergabe weiterläuft, während der Ausgang zum ISP zurückwandert. Eine Kill-Switch-Regel scheitert stattdessen geschlossen, und der Fernseher meldet nichts, bis der Tunnel zurückkehrt. Keines der beiden Verhaltensweisen ist falsch; nicht zu wissen, welche man konfiguriert hat, ist es.
Prüfen Sie nach jeder Änderung vier Dinge in dieser Reihenfolge. Der Selektor passt nach dem nächsten Lease oder Neustart noch zum Gerät. Der Resolver antwortet auf dem Pfad, den die Richtlinie beabsichtigt, statt von einem Server, den sich das Gerät gemerkt hat. Die Adressfamilie in der Richtlinie deckt jede Familie ab, die der Fernseher und das Zugangsnetz tatsächlich nutzen. Casting findet den Fernseher noch vom Telefon, das wirklich verwendet wird, nicht von einem Testtelefon im selben SSID.
Halten Sie diese vier Zeilen neben der Routerkonfiguration statt in einem Chat-Thread fest: was die Regel abgleicht, welchen Resolver der Fernseher fragt, welche Familie abgedeckt ist und welchen lokalen Pfad das Casting braucht. Die nächste Person, die die Firewall öffnet, liest die Konfiguration lange bevor sie ein Ticket liest. Bis dahin sind Sie vielleicht diese Person.