Documentation
Multicast et mDNS à travers Tailscale : pourquoi ça ne passe pas
Le ping passe, SSH passe, mais l'imprimante reste invisible, le Chromecast n'apparaît pas et le jeu ne trouve aucune partie LAN. Si vous vivez cela à travers Tailscale, rien n'est cassé : la découverte d'appareils repose sur la diffusion de lien local, qu'un réseau L3 routé ne transporte pas — un choix d'architecture des mesh WireGuard, pas un défaut. Cette page explique le mécanisme, passe en revue les contournements, puis présente une approche structurellement différente : un mesh qui est un domaine de diffusion.
Le symptôme : la connectivité est parfaite, la découverte reste vide
Le tableau est toujours le même. Les machines sont bien connectées : elles se pinguent par leur adresse du mesh, SSH et les partages par IP fonctionnent sans reproche. Mais tout ce qui repose sur « voir les appareils autour de soi » reste désespérément vide :
- Le jeu n'affiche aucune partie LAN, alors que les deux joueurs sont sur le même réseau Tailscale.
- L'imprimante ou le scanner du bureau distant n'apparaît pas dans la liste des appareils.
- Chromecast, AirPlay ou le téléviseur ne sont pas proposés comme cibles de diffusion.
- Deux nœuds ROS 2 sur des machines différentes ne se découvrent pas : les topics restent muets d'une machine à l'autre.
- Les annonces UDP d'un automate ou d'un capteur n'arrivent jamais sur le poste de supervision.
L'explication : la découverte repose sur la diffusion de lien local
Sur un LAN, les appareils ne se trouvent pas par magie : ils s'annoncent « à tout le monde sur le lien ». mDNS/Bonjour (imprimantes, Chromecast, AirPlay), SSDP/UPnP (téléviseurs, box multimédia), WS-Discovery (caméras ONVIF), la découverte DDS de ROS 2 et les lobbies des jeux LAN envoient des paquets broadcast ou multicast de lien local. Ces paquets sont, par définition, confinés au segment : ils ne franchissent pas un routeur, et les piles strictes rejettent même tout paquet qui aurait été routé.
Tailscale est un mesh bâti sur WireGuard : il établit des tunnels unicast chiffrés point à point entre les machines et présente à chacune un réseau L3 routé. C'est un modèle simple, robuste et éprouvé — mais un réseau routé transporte des paquets vers une destination, il ne diffuse pas. Un paquet mDNS émis d'un côté n'a aucun chemin vers les autres membres : personne ne le réplique, personne ne le reçoit.
D'où le paradoxe apparent : l'unicast (ping, SSH, HTTP) traverse parfaitement, pendant que toute la couche de découverte — celle qui rend un LAN agréable — disparaît. Selon la documentation publique de Tailscale, la diffusion et le multicast ne sont pas pris en charge nativement, et la découverte mDNS/SSDP y est limitée. NetBird, autre mesh WireGuard, fait le même choix d'architecture.
Les contournements habituels côté L3, et leurs limites
Sur un réseau routé, on peut souvent contourner le problème service par service. Ces approches fonctionnent, mais aucune ne restitue le comportement général d'un LAN :
- Forcer l'unicast quand l'application le permet : ajouter l'imprimante par son adresse IP, saisir l'IP du serveur de jeu quand le jeu offre une connexion directe, déclarer une liste de pairs unicast dans la configuration DDS de ROS 2.
- Configurer service par service : chaque application qui repose sur la découverte demande sa propre solution, à documenter et à maintenir à chaque changement d'adresse ou d'appareil.
- Relayer la découverte par un logiciel tiers : des réflecteurs mDNS existent en technique générale de réseau routé, au prix d'un composant supplémentaire à installer et à opérer sur chaque site.
La limite commune est structurelle : ces contournements traitent des cas particuliers, pas la cause. Quand une application ne propose que la découverte automatique — c'est le cas de nombreux jeux LAN et de la plupart des appareils grand public — il n'existe pas de solution générale du côté d'un réseau qui ne transporte pas la diffusion.
L'approche structurellement différente : un mesh qui est un domaine de diffusion
L'autre voie ne consiste pas à contourner l'absence de diffusion, mais à la restituer. VIGIL-MESH traite chaque réseau comme un domaine de diffusion L2 : broadcast, multicast et link-local IP sont répliqués vers tous les membres, comme si chacun était branché sur le même commutateur — où qu'il soit physiquement. mDNS, SSDP, WS-Discovery, la découverte DDS de ROS 2 et les jeux LAN traversent le mesh chiffré comme sur un switch.
- La diffusion est chiffrée de bout en bout : chaque émetteur multicast diffuse sous une clé d'émetteur en rotation, et le relais réplique les paquets sans pouvoir les lire.
- Le transport est du QUIC avec TLS 1.3 de bout en bout, avec un chemin direct entre pairs et une migration sans coupure du relais vers le direct.
- Zéro port entrant sur les nœuds : la diffusion retrouvée ne demande aucune ouverture de pare-feu.
- Le reste du mesh fait le même travail qu'un mesh classique : pair à pair, gestion centralisée, routes vers un LAN distant.
Réseau routé L3 vs domaine de diffusion L2
| Comportement | Mesh L3 routé (unicast) | Domaine de diffusion L2 (VIGIL-MESH) |
|---|---|---|
| Unicast : ping, SSH, HTTP | Oui | Oui |
| Broadcast et multicast de lien local | Non transporté, par conception | Répliqué vers tous les membres, chiffré |
| Découverte mDNS / SSDP / WS-Discovery | Limitée — contournements service par service | Comme sur un LAN |
| Jeux LAN | Selon le jeu, connexion par IP directe si elle existe | Découverte de parties comme sur un même switch |
| Multicast DDS / ROS 2 | Limité — pairs unicast à configurer | Multicast IP répliqué (validation ROS 2 sur la roadmap) |
Aucune colonne n'est « la bonne » dans l'absolu : si vos usages sont purement unicast, un mesh L3 routé vous sert très bien. La colonne de droite compte le jour où la découverte, le multicast applicatif ou les jeux LAN font partie du besoin.