mDNS sur WireGuard : trois portes avant qu'un pair réponde
Avahi a besoin d'une interface éligible, d'une route vers le groupe et d'un pair qui possède la destination. Trois portes, trois vérifications distinctes et aucun déploiement en éventail.
Poser l'indicateur multicast sur un appareil WireGuard rend l'interface éligible aux logiciels de découverte, et c'est tout ce que fait cet indicateur. Il ne dit pas au protocole où doit aller un paquet de groupe, et sur un appareil comptant plusieurs pairs il n'existe pas de réponse évidente unique. Trois portes distinctes séparent un démon en cours d'exécution d'un service découvert.
Testez-les dans l'ordre, car en franchir une ne vous dit rien sur la suivante.
Première porte : l'indicateur et la politique du démon
Un appareil WireGuard sous Linux est créé comme une liaison point à point sans ARP, et il ne porte pas l'indicateur multicast par défaut. Ajouter l'indicateur est une modification locale d'interface, effectuée par ce qui gère l'appareil. Avahi a sa propre vision du monde par-dessus, et sa politique par défaut ignore entièrement les interfaces point à point. Deux tests d'éligibilité indépendants s'appliquent donc avant qu'un seul paquet ne bouge.
Le démon a donc besoin d'une décision explicite, et pas seulement d'un processus en cours d'exécution. Ses contrôles documentés incluent allow-interfaces, deny-interfaces et allow-point-to-point, et le dernier est le réglage que les gens oublient.
Les vérifications ci-dessous rapportent les indicateurs de la liaison, la route multicast et si la configuration du démon est analysée tout court :
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkUn démon démarré avec succès n'a pas forcément ouvert de sockets sur l'interface qui vous intéresse. Lisez sa configuration effective au lieu de supposer que l'état du service équivaut à la couverture.
Deuxième porte : la route vers le groupe
La deuxième porte est le routage ordinaire. Un paquet adressé à 224.0.0.251 suit la table de transfert comme tout le reste, et si la table l'envoie par l'interface LAN physique, aucune configuration WireGuard n'y changera rien. Corrigez d'abord la route et le reste de l'enquête raccourcit. Regardez ce que le noyau rapporte pour l'adresse de groupe avant de toucher à quelque clé de pair que ce soit.
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
Sans route spécifique, le noyau retombe sur le traitement multicast propre à la liaison, ce qui explique que le comportement par défaut paraisse correct sur un LAN plat et faux dès que le même trafic de groupe doit sortir par un tunnel. La panne est silencieuse côté émetteur : la requête part quelque part, et la réponse n'arrive jamais.
Troisième porte : WireGuard choisit un pair par paquet
WireGuard sélectionne un pair sortant en recherchant la destination dans les ensembles d'adresses autorisées, et le chemin de transmission Linux effectue cette recherche une fois par paquet. Il n'y a qu'un résultat, et le paquet est chiffré pour ce pair. Le même préfixe de groupe présent dans les listes autorisées de plusieurs pairs ne crée ni appartenance ni réplication ; il crée une recherche ambiguë qui se résout sur l'un d'eux.
Sur une liaison dédiée à deux extrémités, c'est exactement ce que vous voulez, car il y a un destinataire prévu pour le trafic de groupe transporté délibérément. Sur une interface à cinq pairs, c'est une limitation, pas une fonctionnalité, et le correctif relève de la conception et non de la configuration d'un pair particulier.
Une conception en éventail nécessite un relais explicite, des liaisons séparées ou un mécanisme de découverte entièrement différent. Publier une recette à deux extrémités comme solution multi-clients parce que chaque client peut pinger la passerelle, c'est ainsi que cela se déploie mal.
La direction entrante se vérifie autrement : la source d'un paquet reçu doit tomber dans la liste autorisée du pair authentifié. Y ajouter une destination multicast ne remplace pas la propriété réelle de la source de l'émetteur.
La réflexion est une frontière, pas un pont
Le réflecteur d'Avahi reproduit les messages mDNS entre les interfaces qu'il sélectionne, au niveau applicatif. C'est une frontière de découverte entre réseaux, ni un pont Ethernet ni un routeur multicast général. Deux réflecteurs reliés aux mêmes réseaux créeront volontiers une boucle d'annonces répétées.
La réflexion livre aussi les noms de services et leurs métadonnées à un autre réseau, ce qui est une décision de confidentialité autant qu'une décision de routage. Restreignez les interfaces sélectionnées, et utilisez des filtres de service là où la version installée les prend en charge, afin que seules les annonces dont un utilisateur autorisé a besoin franchissent la frontière.
Découverte et usage restent des résultats distincts. Un client peut voir l'annonce d'un service dont l'adresse annoncée est injoignable depuis l'endroit où il se trouve, ou dont son port est refusé par sa politique d'accès. Confirmez la connexion au service une fois l'annonce apparue, et si l'application prend en charge un nom DNS stable ou une adresse de serveur explicite, préférez cela à l'extension de la découverte locale au lien. La description du routage par clé cryptographique couvre la sélection de pair fondée sur la destination dont tout cela dépend.