Heya collègues codeurs/développeurs/réseauteurs/Devops/...
J'ai un problème avec un mDNS
/DNS-SD
configuration dans le contexte de WSL2 (version Windows 10 2004)
J'ai une configuration assez simple à la maison avec un serveur principal et un Raspberry Pi, et je voudrais activer la découverte de service DNS, me permettant ainsi d'avoir un moyen simple de faire la découverte automatique de mon serveur sur mon Raspberry Pi.
En utilisant une bibliothèque simple comme dnssd , ou même en diffusant les bonnes données moi-même, j'arrive à le faire fonctionner facilement lorsque je n'utilise pas WSL2. Cependant, j'ai besoin de le faire fonctionner sur WSL2 et c'est là que les choses se compliquent.
Comme WSL2 fonctionne sur son propre sous-réseau, la diffusion ne fonctionne plus. L'utilisation de mDNS sur un sous-réseau ne fonctionne que dans ce sous-réseau. Cependant, Windows redirige déjà une partie du trafic de diffusion entre l'hôte et WSL.
Ceci est testable facilement: faire un simple Ping
de mon serveur à l'adresse Avahi du Pi qui repose sur mDNS fonctionne.
Sur le côté gauche de l'écran, vous pouvez voir le trafic capturé par Wireshark sur l'interface réseau hôte et sur le côté droit, vous pouvez voir le trafic capturé par Wireshark sur l'interface réseau WSL. Les 3 premières lignes sont un simple ping: il est exécuté dans le contexte de WSL, mais l'adresse IP qui apparaît ici - 172.28.192.1
- n'est pas l'adresse IP du client WSL, c'est l'adresse IP du serveur DNS interne de WSL. Il est parfaitement redirigé sur l'hôte comme vous pouvez le voir sur la droite, avec l'adresse IP de l'hôte windows: 192.168.0.39
Cependant, la deuxième requête, qui est exécutée par un script, a l'adresse IP source WSL (172.28.204.42
) et celui-ci n'est pas réacheminé sur l'hôte.
Ma connaissance du réseau est très limitée et je ne comprends pas comment cela fonctionne et comment je pourrais faire en sorte que WSL achemine mes propres requêtes mDNS sur l'hôte. Une supposition sauvage serait que cela a quelque chose à voir avec iptables, mais c'est aussi loin que je vais.
Si quelqu'un a une idée de la raison pour laquelle cela fonctionne sur l'adresse source du serveur DNS et non lorsque je l'exécute moi-même, cela m'aiderait beaucoup!
Le commutateur réseau WSL2 Hyper-V n'agit pas comme un pont de multidiffusion. Par défaut, le commutateur crée un réseau interne. Les paquets de multidiffusion ne sont livrés qu'aux systèmes connectés au réseau interne et à rien au-delà. Plus d'informations sur les types de réseau Hyper-V peuvent être trouvées dans ce billet de blog Nakivo .
Dans votre premier cas, le ping déclenche une recherche DNS régulière qui va au résolveur - l'hôte Windows. L'hôte Windows effectue ensuite une recherche mDNS sur ses réseaux externes et internes. Votre vidage de paquets affiche la recherche interne, mais notez que rien n'y répond. La réponse vient via le réseau externe, et le ping obtient sa réponse via un DNS normal. Dans votre deuxième cas, vous effectuez uniquement une recherche mDNS. Cette recherche ne reçoit aucune réponse, car elle va uniquement vers le réseau interne. Pour prouver que les recherches mDNS fonctionnent sur le réseau interne, effectuez une recherche pour l'adresse locale de l'hôte Windows (MACHINE.local). Cela fonctionnera, car l'hôte Windows est sur le réseau interne et peut répondre.
La bonne nouvelle est que vous pouvez modifier le type de réseau WSL.
Après cela, redémarrez WSL:
> wsl --shutdown
> wsl -t <distribution-name>
> wsl --distribution <distribution-name>
Une fois redémarré, le réseau de votre invité sera interrompu. Vous devrez ajouter une adresse IP et un itinéraire depuis votre réseau externe en utilisant ip addr add
et ip route
ou quelque chose de similaire. Votre distribution va presque certainement essayer de configurer son réseau pour le commutateur WSL par défaut à chaque démarrage, vous devrez donc peut-être configurer des configurations pour ajouter cette adresse réseau externe à l'avenir. Par exemple, Ubuntu 20.04 ajoute toujours une adresse dynamique sur le réseau interne, quelle que soit la configuration du commutateur.
La modification du type de commutateur réseau interrompra probablement d'autres utilisations de WSL2 (par exemple, Docker Desktop) pour la même raison. Windows recrée le commutateur réseau Hyper-V chaque fois qu'il redémarre, de sorte que votre modification ne durera que tant que votre système restera actif.