La diffusion s'arrête sous VPN : découverte, contrôle ou flux ?

La diffusion casse à trois endroits qui, du canapé, se ressemblent. Le téléphone peut ne jamais voir le récepteur, le récepteur peut apparaître puis refuser la session, ou la session peut démarrer et caler une minute plus tard. Un tunnel sur le téléphone modifie chacun de ces chemins différemment, et pour l'un d'eux il ne change rien du tout. Nommez d'abord l'étape qui échoue, puis décidez si un changement de politique est vraiment le bon levier.

Nommez l'étape qui échoue avant de changer la politique

Regardez ce que fait le téléphone juste après avoir touché l'icône de diffusion. Une liste vide est un résultat de découverte, une touche qui signale un échec est un résultat de contrôle, et une session qui démarre avant de caler est un résultat de lecture. Ces trois-là ont des propriétaires différents, et seuls les deux premiers concernent normalement les réglages de tunnel du téléphone.

Notez l'étape avant de changer quoi que ce soit. Un correctif appliqué à la mauvaise étape rend le test suivant illisible, et la plupart des légendes sur la diffusion viennent exactement de cette confusion.

La découverte est du trafic local, et un tunnel la masque

Les récepteurs s'annoncent par des annonces locales et le téléphone les trouve par des requêtes sur le même lien, donc tout ce qui retire le téléphone de ce lien retire le récepteur de la liste. Un tunnel qui achemine tout le trafic hors du LAN peut masquer ces échanges, et une autorisation de réseau local au niveau de l'application peut les bloquer même lorsque la route existe. Un Wi-Fi invité avec isolation des clients produit la même liste vide sans aucun VPN. Prouvez que les deux appareils partagent un segment avant d'accuser le tunnel.

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

La première commande liste ce qui s'annonce sur le segment de la machine auxiliaire, et la seconde interroge directement le groupe DNS multicast. Un récepteur absent des deux n'apparaîtra pas non plus dans une application du téléphone, quel que soit l'état du tunnel. Si le récepteur est visible depuis un appareil dont le tunnel est coupé et invisible depuis un appareil dont le tunnel est actif, vous avez trouvé l'étape et la cause ensemble.

Une exception LAN garde le tunnel actif

De nombreux clients proposent une exception de réseau local qui laisse le tunnel actif tout en autorisant les adresses locales. Utilisez ce réglage documenté plutôt que de désactiver le kill switch ou tout le pare-feu, car ceux-ci changent bien plus que ce dont la diffusion a besoin. Si le réseau sépare volontairement les appareils intelligents, demandez au propriétaire le trafic précis de découverte, de contrôle et de retour au lieu d'un accès plat.

nc -vz 192.168.1.50 8009

Un test de contrôle vers le récepteur sépare l'autorisation de l'accessibilité : un port qui répond signifie que le chemin existe, tandis qu'un refus signifie que le téléphone a été autorisé à découvrir l'appareil et ne peut toujours pas lui parler. Les ports 8008 et 8009 sont les ports de diffusion habituels, et une application peut en utiliser d'autres, donc traitez un seul port refusé comme un indice et non comme un verdict. L'exception et l'autorisation de l'application restent indépendantes, car accorder un accès local ne crée pas de route et ajouter une route n'accorde pas d'autorisation. Un kill switch peut aussi faire tomber le trafic local après une reconnexion, et c'est pourquoi la découverte doit être retestée dès que le tunnel revient.

La lecture peut ne pas utiliser la connexion du téléphone

Dans une session pilotée par l'application, le téléphone remet au récepteur une adresse de média et le récepteur la récupère par sa propre connexion, donc changer l'adresse publique du téléphone ne fait rien pour le flux. Un titre limité par un compte peut quand même échouer pour ses propres raisons, et les exigences de diffusion de Google couvrent la compatibilité de l'application et de l'appareil, pas le chemin réseau. Faire passer le téléviseur lui-même par un tunnel est une configuration distincte, avec ses propres questions de politique.

Deux indices distinguent les modes. Une diffusion qui survit au verrouillage de l'écran du téléphone est pilotée par l'application, car le récepteur récupère de lui-même ; un miroir qui s'arrête quand l'écran de l'émetteur se verrouille est un flux continu depuis le téléphone. Quand la découverte et le contrôle réussissent mais que la lecture cale, regardez plutôt la liaison Wi-Fi du récepteur et son chemin vers internet, car un test de débit sur le téléphone décrit le téléphone et non le téléviseur.

Annulez l'exception et retestez

Tout changement temporaire a besoin d'un chemin de retour, et l'ordre compte. Retirez l'exception LAN, reconnectez le tunnel pour que le client réapplique sa politique, puis répétez l'étape de découverte et notez si le récepteur disparaît à nouveau. Cette séquence vous dit si l'exception faisait le travail ou si autre chose a changé entre-temps.

# 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'

Vérifiez ensuite les trois étapes séparément, car réussir l'une ne dit rien des autres. Vérifiez ensuite que les applications du téléphone sans rapport suivent toujours la route prévue, car une exception locale devenue discrètement un contournement complet est un résultat pire qu'une diffusion qui demande une touche de plus.