Pourquoi la diffusion cesse de fonctionner après avoir activé le VPN du routeur
La découverte passe par le multicast local tandis que le téléviseur récupère les médias lui-même. Une politique par défaut peut capturer la requête du réseau local et l’envoyer dans le tunnel.
La diffusion fonctionnait avant l’activation du VPN du routeur et échoue immédiatement après, alors que la navigation ordinaire sur le téléphone continue de fonctionner. Les deux faits sont cohérents, car la diffusion n’est pas une seule connexion. Le téléphone découvre et contrôle le récepteur sur le réseau local, puis le récepteur récupère les médias par sa propre connexion.
Deux chemins qui échouent différemment
Le chemin de contrôle est local. Un téléphone trouve un récepteur en interrogeant le réseau local, puis ouvre une connexion de contrôle vers l’adresse qu’il a apprise. Si le récepteur n’apparaît jamais dans la liste, l’étape de découverte a échoué avant qu’un média soit demandé.
Le chemin des médias n’est pas nécessairement local. Beaucoup de récepteurs récupèrent le flux eux-mêmes, par leur propre connexion et avec leurs propres identifiants, donc la route du téléphone ne décrit pas la route du récepteur. Un téléphone qui semble utiliser une sortie ne dit rien de l’endroit où va le trafic du téléviseur.
Cette séparation est la raison pour laquelle la panne paraît étrange. Le tunnel a modifié la table de routage du téléphone et pas celle du téléviseur, donc un symptôme qui apparaît d’un côté de la paire doit être tracé de ce côté. Tracer le mauvais appareil est la raison habituelle pour laquelle une correction semble ne rien faire.
Pourquoi la découverte casse en premier
La découverte passe généralement par le multicast de lien local. mDNS envoie vers 224.0.0.251 sur le port UDP 5353, et SSDP envoie vers 239.255.255.250 sur le port UDP 1900. Les deux sont limités à un lien par conception, ce qui explique qu’un routeur ne les transmet pas entre segments sans l’aide d’un répéteur ou d’un proxy. Un VPN routé n’étend pas un groupe multicast, et une route de politique ne peut pas faire apparaître sur un autre lien un groupe qui n’a jamais quitté le sien.
La première panne n’a donc rien à voir avec le chiffrement. Le multicast du téléphone quitte l’interface sur laquelle il a été envoyé, le récepteur est sur un segment qui ne le voit jamais, et la liste des appareils revient vide. Une liste vide n’est pas la preuve que le téléviseur a perdu son accès à internet.
L’isolement produit un symptôme identique sans aucun VPN. Les réseaux invités et l’isolement des clients sur les points d’accès empêchent délibérément les appareils de se parler, et activer un VPN de routeur par-dessus un segment isolé n’y change rien. Vérifiez le réglage d’isolement avant de vérifier le tunnel. C’est la réponse la moins chère et la plus fréquente.
La disposition des segments est l’autre moitié. Un second routeur, un nœud mesh dans un autre mode ou un segment filaire derrière un autre NAT placent tous le récepteur là où le trafic de découverte du téléphone n’arrive pas.
Pourquoi une politique par défaut peut avaler une requête locale
Un routeur qui achemine tout le trafic dans un tunnel installe une route par défaut sur l’interface du tunnel. Si le préfixe du réseau local n’est pas exclu de cette politique, un paquet adressé à un appareil situé à deux mètres correspond désormais à la route par défaut, et le routeur envoie la requête de contrôle dans le tunnel au lieu du commutateur.
| 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 |
L’ordre des règles décide du résultat. Le routage par politique évalue les règles par ordre de priorité, donc une exception pour le préfixe local doit apparaître avant la règle qui sélectionne la table du tunnel. Ajouter l’exception après la règle du tunnel n’a aucun effet, ce qui explique qu’une configuration qui semble correcte puisse encore envoyer le trafic local vers une sortie distante.
La réparation est étroite : autorisez les destinations locales précises dont le flux de diffusion a besoin, et laissez le reste de l’isolement tranquille. Retirer l’isolement des clients comme première étape corrige le symptôme mais abandonne un contrôle que le réseau était censé avoir.
Une vérification rapide sur le téléphone détermine laquelle des deux pannes vous avez. Si la route vers le récepteur pointe vers le tunnel, la politique est le problème. Si elle pointe vers le réseau local et que la découverte échoue toujours, le multicast ou l’isolement est le problème, et aucun changement de route n’aidera.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTestez l’étape qui a changé, pas le pays
Les observations consignées valent mieux que les expériences répétées. Notez si le récepteur apparaît dans la liste des appareils, si une requête de contrôle l’atteint et si la lecture démarre une fois un flux choisi. Chaque réponse retire une étape des soupçons.
Testez ensuite chaque étape directement plutôt que de changer de sortie. Changer de pays de VPN teste le chemin des médias et laisse intactes les étapes de découverte et de contrôle, donc cela peut sembler aider par accident sans rien vous apprendre.
Côté récepteur, vérifiez sa propre route et l’état de son compte. Un téléviseur qui récupère les médias par une sortie différente de celle du téléphone est une conception normale, et une panne à cet endroit est une question de politique réseau du récepteur, non du tunnel du téléphone.
Notez le résultat en une seule phrase sur l’étape qui a cassé et ce qui l’a changée. Cette phrase vaut plus qu’une semaine de changements de pays, et elle survit à la prochaine mise à jour du micrologiciel.
La diffusion est un bon cas de test pour une règle générale sur les tunnels. Quand on en ajoute un à un réseau, la première question est quelles destinations n’auraient jamais dû y entrer. La seconde est lesquelles de ces destinations la politique a malgré tout acceptées en silence.