Smart TV sur le VPN : pourquoi le cast et le DNS cassent séparément
Acheminez le trafic du téléviseur au routeur, puis traitez le sélecteur, le résolveur, IPv6 et le chemin de cast comme quatre vérifications distinctes.
Votre téléviseur affiche le catalogue étranger, et le bouton de cast du téléphone ne le liste plus. Les deux plaintes commencent par une phrase qui nomme quatre réglages sur quatre pages du routeur. Réparez la sortie et la découverte casse ; réparez la découverte et le prochain bail confie la sortie à un autre appareil. L'ordre ci-dessous va du sélecteur au chemin de cast.
Où vit chacune des quatre décisions
Notez les quatre avant d'ouvrir un menu, car chacune vit sur une page différente et échoue à un endroit différent. Le sélecteur choisit à quel client le tunnel s'applique, le résolveur décide où les noms sont résolus, la famille d'adresses décide si IPv6 est couvert du tout, et le chemin local décide si le téléphone et le téléviseur se voient encore. Un changement sur l'une paraît complet depuis la page où vous êtes. Les dégâts des trois autres apparaissent plus tard, dans un autre menu, comme une autre plainte.
Les menus du firmware diffèrent, mais les quatre emplacements rarement. Le sélecteur est un mappage statique sur le serveur DHCP plus une règle de pare-feu qui y correspond. Le résolveur siège avec le service DNS, où une entrée de redirecteur ou une liste de serveurs amont décide quels noms le routeur résout et d'où partent les requêtes. Le réglage de famille appartient à l'interface elle-même, où IPv4 et IPv6 se configurent séparément et où une politique ne peut couvrir que la première. Le chemin local est un commutateur du point d'accès, soit l'isolation des clients, soit un réseau invité avec son propre pare-feu.
Faites durer le sélecteur plus longtemps que le bail
Une politique par appareil et un segment dédié fonctionnent tous deux, et le meilleur choix est celui que le firmware peut maintenir sans qu'une seconde personne s'en souvienne. Le piège est une règle épinglée à une adresse que le serveur DHCP a attribuée selon son propre calendrier : elle fonctionne jusqu'à ce que le bail bouge, puis route un ordinateur portable par un autre pays pour des raisons que son propriétaire ne peut voir. La persistance, pas la propreté, est la propriété qui vaut la peine d'être optimisée.
| 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 |
Envoyez la réservation et la règle comme un seul changement, car une règle qui survit à sa réservation vise le matériel de quelqu'un d'autre. Une règle de segment entier est le sélecteur le plus durable et le plus grossier, puisque chaque appareil derrière cette interface hérite de la sortie, qu'il en ait eu besoin ou non. Quel que soit le sélecteur choisi, la question de la couverture vient ensuite : une politique IPv4 seule est une demi-décision, et la famille non couverte est celle qui part sans être remarquée.
Découvrez quel résolveur le téléviseur utilise vraiment
Ouvrez les réglages réseau du téléviseur lui-même avant de toucher au routeur, car l'appareil tranche ce débat. Un champ DNS réglé en manuel continue d'utiliser ce serveur quoi qu'offre le DHCP, et un décodeur configuré une fois pour une autre région peut encore pointer vers une adresse qui ne répond plus. Si le champ est automatique, l'option DHCP du routeur décide, et le résolveur du routeur devient la question suivante. Dans les deux cas, la réponse est sur l'écran de l'appareil, pas dans le manuel du firmware.
Côté routeur, la distinction qui compte est entre les noms auxquels le routeur répond lui-même et les noms qu'il transmet, car ces deux chemins peuvent sortir par des interfaces différentes. Une requête qui se résout correctement ne dit donc rien sur la destination d'une demande multimédia, et sur une passerelle Linux la table de politiques plus une seule recherche de route répondent aux deux questions sans rien capturer sur le téléviseur :
ip rule show
ip route get 203.0.113.10Lisez la première commande pour la règle qui marque le trafic du téléviseur et la seconde pour l'interface qu'un paquet vers l'adresse d'exemple utiliserait réellement. Quand les deux sont en désaccord, le résolveur n'est pas en cause ; la politique l'est. Changez une chose, puis relancez la paire, car une liste de règles est sensible à l'ordre et une nouvelle entrée peut masquer la règle qui portait le trafic. La destination est réservée à la documentation, donc une sortie collée se lit comme un exemple.
Le cast casse à la découverte, pas au flux
Le cast est au moins trois conversations et une seule porte la vidéo. Le téléphone découvre le téléviseur par multicast ou broadcast sur le segment local, ouvre un canal de contrôle pour dire quoi lire, puis le téléviseur soit récupère le flux lui-même, soit le reçoit relayé depuis le téléphone. La découverte ne traverse jamais un routeur qui ne transmet pas ce trafic, et c'est ainsi qu'un téléviseur peut être routé exactement comme voulu et pourtant n'apparaître jamais dans la liste de cast.
Les réseaux invités et l'isolation des clients sont la cause habituelle, et les deux font exactement ce pour quoi ils ont été configurés. Désactiver l'isolation sur tout le réseau sans fil pour qu'un appareil réapparaisse est la surcorrection habituelle, et elle rouvre chaque chemin téléphone-à-téléphone que le réglage existait pour fermer. Il existe des réponses plus étroites : une règle de passage pour le trafic de découverte et de contrôle entre deux adresses, un SSID séparé pour les téléviseurs, ou une exception documentée sur le réseau invité.
Testez le cast avec la règle d'isolation toujours en place, puis ajoutez seulement l'exception de découverte et testez à nouveau. Si la seconde tentative trouve le téléviseur, l'exception est la solution et le reste du segment peut rester comme il était.
Arrêtez le tunnel et regardez dans quel sens il échoue
La dernière vérification est celle que la plupart des installations sautent : coupez le tunnel et regardez si le téléviseur s'arrête ou s'en va discrètement par la connexion locale. Une politique qui exprime une préférence échoue ouverte, et cette défaillance est facile à manquer car la lecture continue pendant que la sortie repasse par le FAI. Une règle de kill-switch échoue fermée à la place, et le téléviseur ne signale rien avant le retour du tunnel. Aucun des deux comportements n'est faux ; ne pas savoir lequel vous avez configuré l'est.
Revérifiez quatre choses après tout changement, dans cet ordre. Le sélecteur correspond encore à l'appareil après le prochain bail ou redémarrage. Le résolveur répond sur le chemin que la politique prévoit, non depuis un serveur que l'appareil a mémorisé. La famille d'adresses de la politique couvre chaque famille que le téléviseur et le réseau d'accès utilisent réellement. Le cast trouve encore le téléviseur depuis le téléphone qui sera vraiment utilisé, pas depuis un téléphone de test sur le même SSID.
Gardez ces quatre lignes à côté de la configuration du routeur plutôt que dans un fil de discussion : ce que la règle fait correspondre, quel résolveur le téléviseur interroge, quelle famille est couverte et quel chemin local le cast nécessite. La prochaine personne qui ouvrira le pare-feu lira la configuration bien avant de lire un ticket. D'ici là, cette personne pourrait être vous.