La découverte Chromecast et DLNA ne traverse jamais un VPN routé

Le bouton de diffusion n'affiche rien, VLC DLNA reste vide, et la machine d'en face répond au ping sans se plaindre. Cette combinaison n'est pas un problème de bande passante ni une énigme de pare-feu. La découverte dans ces protocoles est un échange de groupe sur le segment local, et un tunnel routé ne transporte pas le trafic adressé à un groupe. La session que vous essayez de démarrer n'est jamais proposée.

L'accessibilité est correcte. La découverte manque.

Le mythe : le tunnel a besoin d'un réglage ou de plus de débit

Les suggestions habituelles sont d'activer le trafic pair à pair, d'augmenter le MTU ou de changer le type de périphérique du tunnel. Aucune n'ajoute un domaine de diffusion. Le multicast est livré par les commutateurs et par la pile réseau locale, et une interface TUN point à point n'a aucune adresse de groupe à inonder.

Changer les réglages peut rendre la panne plus bruyante. Cela ne peut pas faire apparaître une annonce là où le protocole n'en a jamais envoyé.

Ce qu'est réellement l'échange de découverte

Trois schémas couvrent presque tout ce que vous rencontrerez. mDNS envoie vers 224.0.0.251 sur UDP 5353, SSDP envoie vers 239.255.255.250 sur UDP 1900, et les anciennes listes de navigation SMB allaient vers l'adresse de diffusion du sous-réseau. Chacune s'adresse à un groupe et non à un hôte, et chacune attend un auditeur sur le même segment. Un récepteur de l'autre côté d'un tunnel routé n'est pas sur ce segment, donc rien n'arrive.

Même une annonce relayée porte une charge utile : généralement l'adresse LAN et le port de l'émetteur, que le spectateur distant doit ensuite pouvoir joindre.

Lisez une capture avant de changer le tunnel

Capturez sur l'interface du tunnel pendant que l'application scanne. Une capture vide signifie que l'annonce n'a jamais franchi la frontière, et aucun réglage du tunnel n'y change rien. Les paquets qui apparaissent quand même alors que l'application n'affiche toujours rien signifient généralement que l'adresse annoncée n'est pas joignable depuis le spectateur : c'est un problème de routage déguisé en découverte.

Deux minutes de capture remplacent une heure de suppositions sur les ports : tcpdump -ni tun0 udp port 5353 or udp port 1900.

Trois solutions, la moins chère d'abord

Pointez le client directement vers l'adresse du service. Pour DLNA, SMB et les serveurs multimédias simples, cela saute entièrement la découverte et prouve que le chemin de la charge utile fonctionne, ce qui en fait le meilleur premier test et aussi un contournement utilisable. Chromecast est l'exception, car le récepteur attend d'être trouvé plutôt que d'être adressé.

Relayez le protocole à la passerelle. Un réflecteur mDNS répète les annonces entre le tunnel et le LAN, et Avahi fournit une section réflecteur qui accepte une liste d'interfaces explicite. Gardez le relais étroit et confirmez que l'adresse annoncée est joignable des deux côtés, sinon la réponse pointe encore vers un sous-réseau que le spectateur ne peut pas router.

Brigez au lieu de router. Un segment TAP où le serveur ponte l'interface tap sur le LAN place les deux extrémités dans un même domaine de diffusion, donc les annonces passent sans changement. C'est aussi l'option la plus coûteuse, car un seul sous-réseau signifie un seul domaine de panne et chaque service multicast du LAN atteint désormais chaque pair.

Ce qui n'aide pas, quelle que soit la fréquence des conseils

Passer de dev tun à dev tap sans pont laisse une interface TAP toujours routée, donc le comportement ne change pas. client-to-client autorise l'unicast entre pairs et n'inonde pas les diffusions. Rediriger un port de découverte vers un seul hôte ne livre pas de trafic adressé à un groupe. Un serveur multimédia lié à une adresse continue de répondre sur cette adresse jusqu'à ce que sa propre configuration liste l'interface VPN.

Testez une requête unicast directe, puis une requête annoncée. Si la première fonctionne et la seconde non, le tunnel est sain et la découverte est tout le problème.