Entrainement
Parcours d’apprentissage
Configurer la mise en réseau sur Windows clients - Training
MD-100 Configurer la mise en réseau sur Windows clients
Ce navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
Nous avons abordé certains scénarios de résolution des problèmes courants associés à WSL ci-dessous, mais nous vous invitons à effectuer aussi des recherches dans les problèmes signalés dans le dépôt du produit WSL sur GitHub.
Les problèmes signalés dans le dépôt du produit WSL vous permettent d’effectuer les opérations suivantes :
cmd.exe /c ver
pour afficher votre numéro de build actuelle), indiquer si vous exécutez WSL 1 ou 2, votre numéro de version de noyau Linux actuelle (exécutez wsl.exe --status
ou cat /proc/version
), le numéro de version de votre distribution (exécutez lsb_release -r
), les autres versions logicielles impliquées, les étapes de reproduction, le comportement attendu, le comportement réel et les journaux de diagnostic s’ils sont disponibles et appropriés. Pour plus d’informations, consultez Contribution à WSL.Vous pouvez également :
Échec de l’installation avec l’erreur 0x80070003
C:
). Vérifiez que les distributions sont stockées sur votre lecteur système :Échec de WslRegisterDistribution avec l’erreur 0x8007019e
Échec de l’installation avec l’erreur 0x80070003 ou l’erreur 0x80370102
Erreur lors d’une tentative de mise à niveau : Invalid command line option: wsl --set-version Ubuntu 2
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
.Impossible de terminer l’opération demandée du fait d’une limitation du système de disque virtuel. Les fichiers de disque dur virtuel doivent être décompressés et déchiffrés, mais ne doivent pas être partiellement alloués.
%USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
wsl --set-version
devrait fonctionner.Notes
Dans mon cas, le dossier LocalState pour ma distribution Ubuntu 18.04 se trouvait sur C:\Users<mon-nom-utilisateur>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc
Consultez le thread GitHub n° 4103 de la documentation WSL où ce problème est suivi pour obtenir des informations mises à jour.
Le terme « wsl » n’est pas reconnu comme nom d’applet de commande, fonction, fichier de script ou programme exécutable.
wsl.exe
à partir de PowerShell Core ou d’une invite de commandes.Erreur : Lee Sous-système Windows pour Linux n’a aucune distribution installée.
\Windows\sysnative
. Notez qu’il ne sera pas sur le disque, mais le programme de résolution de chemin de système de fichiers le trouvera.Error: Cette mise à jour s’applique seulement aux machines avec le sous-système Windows pour Linux.
This update only applies to machines with the Windows Subsystem for Linux
.Vous êtes toujours dans une ancienne version de Windows qui ne prend pas en charge WSL 2. Consultez l’étape 2 pour connaître la configuration requise de la version et obtenir des liens de mise à jour.
WSL n’est pas activé. Vous devez revenir à l’étape 1 et vous assurer que la fonctionnalité facultative WSL est activée sur votre machine.
Une fois que vous avez activé WSL, un redémarrage est nécessaire pour sa prise en compte : redémarrez votre machine, puis réessayez.
Erreur : WSL 2 requiert une mise à jour de son composant noyau. Pour obtenir des informations, consultez https://aka.ms/wsl2kernel.
C’est probablement dû au fait que votre ordinateur n’a pas encore utilisé le rétroportage pour WSL 2. La façon la plus simple de résoudre ce problème consiste à accéder aux paramètres Windows et à cliquer sur « Rechercher les mises à jour » pour installer les dernières mises à jour sur votre système. Consultez les instructions complètes sur l’utilisation du rétroportage.
Si vous avez cliqué sur « Rechercher les mises à jour » et que vous ne recevez toujours pas la mise à jour, vous pouvez installer manuellement KB4566116.
Cela peut se produire lorsque le paramètre « Langue d’affichage » ou « Paramètres régionaux du système » n’est pas défini sur Anglais.
wsl --set-default-version 2
Error: 0x1bc
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
L’erreur en question pour 0x1bc
est :
WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel
Pour plus d’informations, reportez-vous au problème 5749 :
Un serveur de fichiers utilisant le protocole 9P fournit le service côté Linux pour permettre à Windows d’accéder au système de fichiers Linux. Si vous ne pouvez pas accéder à WSL en utilisant \\wsl$
sur Windows, la raison peut en être que 9P n’a pas démarré correctement.
Pour cela, vous pouvez vérifier les journaux de démarrage en utilisant dmesg |grep 9p
: ceci vous montre les éventuelles erreurs. Une sortie indiquant la réussite se présente comme suit :
[ 0.363323] 9p: Installing v9fs 9p2000 file system support
[ 0.363336] FS-Cache: Netfs '9p' registered for caching
[ 0.398989] 9pnet: Installing 9P2000 support
Pour plus d’informations sur ce problème, consultez ce thread GitHub.
Si votre langue d’affichage n’est pas l’anglais, il est possible que seule une version tronquée d’un texte d’erreur soit affichée.
C:\Users\me>wsl
WSL 2
Pour résoudre ce problème, consultez https://aka.ms/wsl2kernel
et installez le noyau manuellement en suivant les instructions de cette page de la documentation.
Les utilisateurs peuvent exécuter des exécutables Windows tels que notepad.exe directement dans Linux. Parfois, vous pouvez obtenir le message « command not found », comme ci-dessous :
$ notepad.exe
-bash: notepad.exe: command not found
S’il n’existe pas de chemin Win32 dans votre $PATH, Interop ne trouvera pas le fichier .exe.
Vous pouvez le vérifier en exécutant echo $PATH
dans Linux. Normalement, vous devez voir un chemin Win32 (par exemple, /mnt/c/Windows) dans la sortie.
Si vous ne voyez pas de chemin Windows, c’est que votre PATH a probablement été remplacé par votre shell Linux.
Voici un exemple que /etc/profile sur Debian a contribué au problème :
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
La méthode à utiliser pour Debian consiste à supprimer les lignes ci-dessus. Vous pouvez également ajouter des $PATH pendant l’attribution comme ci-dessous. Toutefois, cela entraînera d’autres problèmes avec WSL et VSCode.
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:$PATH"
fi
Pour plus d’informations, consultez les problèmes 5296 et 5779.
Activez la fonctionnalité Windows Plateforme de machine virtuelle et vérifiez que la virtualisation est activée dans le BIOS.
Vérifiez la configuration système pour Hyper-V
Si votre machine est une machine virtuelle, activez manuellement la virtualisation imbriquée. Lancez PowerShell avec les privilèges d’administrateur et exécutez la commande suivante, en remplaçant <VMName>
par le nom de la machine virtuelle sur votre système hôte (vous trouverez le nom dans votre Gestionnaire Hyper-V) :
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
Suivez les instructions du fabricant de votre PC pour savoir comment activer la virtualisation. En général, ceci peut impliquer l’utilisation du BIOS du système pour activer ces fonctionnalités sur votre processeur. Les instructions concernant ce processus peuvent varier d’un ordinateur à l’autre. Pour voir un exemple, consultez cet article de Bleeping Computer.
Redémarrez votre machine après avoir activé le composant facultatif Virtual Machine Platform
.
Assurez-vous que le lancement de l’hyperviseur est activé dans votre configuration de démarrage. Vous pouvez le valider en exécutant (PowerShell avec élévation de privilèges) :
bcdedit /enum | findstr -i hypervisorlaunchtype
Si vous voyez hypervisorlaunchtype Off
, l’hyperviseur est désactivé. Pour l’exécuter dans PowerShell avec élévation de privilèges :
bcdedit /set hypervisorlaunchtype Auto
De plus, si vous avez installé des hyperviseurs tiers (comme VMware ou VirtualBox), vérifiez que vous avez les dernières versions qui peuvent prendre en charge HyperV (VMware 15.5.5+ et VirtualBox 6+) ou qu’ils sont désactivés.
Si vous recevez cette erreur sur une machine virtuelle Azure, vérifiez que le lancement fiable est désactivé. La virtualisation imbriquée n’est pas prise en charge sur les machines virtuelles Azure.
Découvrez plus en détail comment Configurer la virtualisation imbriquée lors de l’exécution d’Hyper-V dans une machine virtuelle.
Les environnements professionnels ou d’entreprise peuvent avoir les paramètres de pare-feu Windows Defender configurés pour bloquer le trafic réseau non autorisé. Si la fusion de règles locales est définie sur « Non », le réseau WSL ne fonctionnera pas par défaut et votre administrateur devra ajouter une règle de pare-feu pour l’autoriser.
Vous pouvez confirmer le paramètre de fusion des règles locales en suivant ces étapes :
Vous trouverez des instructions sur la modification de ce paramètre de pare-feu dans Configurer le pare-feu Hyper-V.
Si, après une connexion à un VPN sur Windows, Bash perd la connectivité réseau, essayez cette solution de contournement à partir de Bash. Elle vous permet de remplacer la résolution DNS manuellement avec /etc/resolv.conf
.
ipconfig.exe /all
et notez le serveur DNS du VPN.sudo cp /etc/resolv.conf /etc/resolv.conf.new
.sudo unlink /etc/resolv.conf
.sudo mv /etc/resolv.conf.new /etc/resolv.conf
/etc/wsl.conf
et ajoutez ce contenu au fichier. (Vous trouverez plus d’informations sur cette configuration dans Configuration des paramètres avancés)[network]
generateResolvConf=false
/etc/resolv.conf
et Une fois que vous avez déconnecté le VPN, vous devez revenir au fichier /etc/resolv.conf
non modifié. Pour ce faire, exécutez les commandes suivantes :
cd /etc
sudo mv resolv.conf resolv.conf.new
sudo ln -s ../run/resolvconf/resolv.conf resolv.conf
Le VPN Cisco AnyConnect modifie les itinéraires d’une manière qui empêche NAT de fonctionner. Il existe une solution de contournement spécifique à WSL 2 : consultez l’article Guide de d’administrateur du Client de mobilité sécurisée Cisco AnyConnect version 4.10 – Résoudre les problèmes liés à AnyConnect.
Le mode réseau en miroir est actuellement un paramètre expérimental dans la configuration WSL. L’architecture de mise en réseau NAT traditionnelle de WSL peut être mise à jour vers un tout nouveau mode réseau appelé « mode réseau en miroir ». Quand le paramètre expérimental networkingMode
est défini sur mirrored
, les interfaces réseau présentes sur Windows sont mises en miroir dans Linux pour améliorer la compatibilité. Pour en savoir plus, consultez le blog sur la ligne de commande : Mise à jour de WSL de septembre 2023.
Certains VPN ont été testés et confirmés comme étant non compatibles avec WSL, notamment :
La mise en miroir du proxy HTTP/S peut être configurée à l’aide du paramètre autoProxy
dans la section expérimentale du fichier de configuration WSL. Lors de l’application de ce paramètre, notez les considérations suivantes :
Une fois cette fonction activée, les points suivants sont appliqués aux paramètres de proxy sur vos distributions Linux :
HTTP_PROXY
est définie sur un ou plusieurs proxys HTTP installés dans la configuration du proxy HTTP Windows.HTTPS_PROXY
est définie sur un ou plusieurs proxys HTTPS installés dans la configuration du proxy HTTP Windows.NO_PROXY
est définie pour contourner les proxys HTTP/S détectés dans les cibles de configuration Windows.WSL_PAC_URL
, est définie en minuscules et en majuscules. Par exemple : HTTP_PROXY
et http_proxy
.Les configurations ZScaler causent un problème connu, où ZScaler active et désactive à plusieurs reprises les configurations de proxy Windows, ce qui entraîne l’affichage répété de WSL montrant la notification « Une modification du proxy HTTP a été détectée sur l’hôte ».
Pour en savoir plus, consultez le blog sur la ligne de commande : Mise à jour de WSL de septembre 2023.
Quand WSL ne peut pas se connecter à Internet, cela peut être dû au fait que l’appel DNS à l’hôte Windows est bloqué. Ce problème est dû au fait que le paquet réseau pour DNS envoyé par la machine virtuelle WSL à l’hôte Windows est bloqué par la configuration réseau existante. Le tunneling DNS corrige ce problème à l’aide d’une fonctionnalité de virtualisation pour communiquer directement avec Windows, ce qui permet de résoudre le nom DNS sans envoyer de paquet de mise en réseau. Cette fonctionnalité doit améliorer la compatibilité réseau et vous permettre d’obtenir une meilleure connectivité Internet même si vous disposez d’un VPN, d’une configuration de pare-feu spécifique ou d’autres configurations réseau.
Le tunneling DNS peut être configuré à l’aide du paramètre dnsTunneling
dans la section expérimentale du fichier de configuration WSL. Lors de l’application de ce paramètre, notez les considérations suivantes :
/etc/resolv.conf
de votre distribution Linux a une limitation maximale de 3 serveurs DNS, tandis que Windows peut utiliser plus de 3 serveurs DNS. L’utilisation du tunneling DNS supprime cette limitation. Tous les serveurs DNS Windows peuvent désormais être utilisés par Linux.Pour en savoir plus, consultez le blog sur la ligne de commande : Mise à jour de WSL de septembre 2023.
Quand vous utilisez le mode réseau en miroir (le paramètre expérimental networkingMode
défini sur mirrored
), une partie du trafic entrant reçu par l’hôte Windows n’est jamais dirigée vers la machine virtuelle Linux. Ce trafic est le suivant :
WSL configure automatiquement certains paramètres de mise en réseau Linux lors de l’utilisation du mode réseau en miroir. Les configurations utilisateur de ces paramètres lors de l’utilisation du mode réseau en miroir ne sont pas prises en charge. Voici la liste des paramètres que WSL configure :
Nom du paramètre | Value |
---|---|
https://sysctl-explorer.net/net/ipv4/accept_local/ | Activé (1) |
https://sysctl-explorer.net/net/ipv4/route_localnet/ | Activé (1) |
https://sysctl-explorer.net/net/ipv4/rp_filter/ | Désactivé (0) |
https://sysctl-explorer.net/net/ipv6/accept_ra/ | Désactivé (0) |
https://sysctl-explorer.net/net/ipv6/autoconf/ | Désactivé (0) |
https://sysctl-explorer.net/net/ipv6/use_tempaddr/ | Désactivé (0) |
addr_gen_mode | Désactivé (0) |
disable_ipv6 | Désactivé (0) |
https://sysctl-explorer.net/net/ipv4/arp_filter/ | Activé (1) |
Il existe un problème connu selon lequel les conteneurs Docker Desktop avec des ports publiés (docker run –publish/-p) ne sont pas créés. L’équipe WSL collabore avec l’équipe Docker Desktop pour résoudre ce problème. Pour contourner le problème, utilisez l’espace de noms réseau de l’hôte dans le conteneur Docker. Définissez le type de réseau via l’option « --network host » utilisée dans la commande « docker run ». Une autre solution de contournement consiste à répertorier le numéro de port publié dans le paramètre ignoredPorts
de la section expérimentale dans le fichier de configuration WSL.
Il existe un problème connu lié aux conteneurs Docker dont le service Gestionnaire de réseau est en cours d’exécution. Les symptômes incluent des échecs lors de la tentative d’établissement de connexions de bouclage à l’hôte. Il est recommandé d’arrêter le service Gestionnaire de réseau pour que la mise en réseau WSL soit configurée correctement.
sudo systemctl disable network-manager.service
Les noms .local sont souvent utilisés pour résoudre les noms d’hôte en adresses IP au sein d’un réseau local sans avoir besoin d’un serveur DNS conventionnel. Cela est réalisé grâce au protocole mDNS (DNS multidiffusion), qui s’appuie sur le trafic multidiffusion pour fonctionner.
networkingMode défini sur NAT :
Actuellement, cette fonctionnalité n’est pas prise en charge lorsque le tunneling DNS est activé. Pour activer la résolution des noms .local, nous vous recommandons les solutions suivantes :
networkingMode défini sur En miroir :
Remarque : Vous devez être sur WSL build version 2.3.17 ou ultérieure pour disposer des fonctionnalités ci-dessous.
Étant donné que le mode En miroir prend en charge le trafic multidiffusion, le protocole mDNS (DNS multidiffusion) peut être utilisé pour résoudre les noms .local. Linux doit être configuré pour prendre en charge mDNS, car il ne le fait pas par défaut. Une façon de le configurer consiste à utiliser les deux étapes suivantes :
sudo apt-get install libnss-mdns
* Le package « libnss-mdns » est un plug-in pour la fonctionnalité Name Service Switch (NSS) de la bibliothèque GNU C (glibc) qui permet la résolution des noms d'hôte via le DNS multidiffusion (mDNS). Ce package permet aux programmes Unix/Linux courants de résoudre les noms dans le domaine mDNS ad hoc .local.
/etc/nsswitch.conf
pour activer le paramètre « mdns_minimal » dans la section « hosts ». Exemple de contenu du fichier :cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat systemd
group: compat systemd
shadow: compat
gshadow: files
hosts: files mdns_minimal [NOTFOUND=return] dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
Selon les configurations du fichier .wslconfig, WSL aura le comportement suivant avec les suffixes DNS :
Lorsque networkingMode est défini sur NAT :
1er cas : par défaut, aucun suffixe DNS n’est configuré dans Linux
2e cas : si le tunneling DNS est activé (dnsTunneling a la valeur true dans .wslconfig), tous les suffixes DNS Windows sont configurés dans Linux, dans le paramètre « search » de /etc/resolv.conf
Les suffixes sont configurés dans /etc/resolv.conf dans l’ordre suivant, comme dans l’ordre dans lequel le client DNS Windows tente les suffixes lors de la résolution d’un nom : les suffixes DNS globaux en premier, puis les suffixes DNS supplémentaires, puis les suffixes DNS par interface.
Lorsqu’il existe une modification dans les suffixes DNS Windows, elle est automatiquement reflétée dans Linux
3e cas : si le tunneling DNS est désactivé et que le proxy DNS SharedAccess est désactivé (dnsTunneling a la valeur false et dnsProxy a la valeur false dans .wslconfig), un suffixe DNS unique est configuré dans Linux, dans le paramètre « domain » de /etc/resolv.conf
Lorsqu’il existe une modification dans les suffixes DNS Windows, elle n’est pas reflétée dans Linux
Le suffixe DNS unique configuré dans Linux est choisi à partir des suffixes DNS par interface (les suffixes globaux et supplémentaires sont ignorés)
Si Windows a plusieurs interfaces, une heuristique est utilisée pour choisir le suffixe DNS unique qui sera configuré dans Linux. Par exemple, s’il existe une interface VPN sur Windows, le suffixe est choisi à partir de cette interface. Si aucune interface VPN n’est présente, le suffixe est choisi à partir de l’interface qui est la plus susceptible d’offrir une connectivité Internet.
Lorsque networkingMode est défini sur Mirrored :
Tous les suffixes DNS Windows sont configurés dans Linux, dans le paramètre « search » de /etc/resolv.conf
Les suffixes sont configurés dans /etc/resolv.conf dans le même ordre que dans le 2e cas à partir du mode NAT
Lorsqu’il existe une modification dans les suffixes DNS Windows, elle est automatiquement reflétée dans Linux
Remarque : des suffixes DNS supplémentaires peuvent être configurés dans Windows à l’aide de SetInterfaceDnsSettings – Applications Win32 | Microsoft Learn, avec l’indicateur DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST défini dans le paramètre Paramètres
La configuration DNS par défaut quand WSL démarre un conteneur en mode NAT consiste à avoir l’appareil NAT sur l’hôte Windows comme serveur DNS pour le conteneur WSL. Lorsque les requêtes DNS sont envoyées du conteneur WSL à cet appareil NAT sur l’hôte Windows, le paquet DNS est transféré de l’appareil NAT au service d’accès partagé sur l’hôte ; la réponse est envoyée dans le sens inverse vers le conteneur WSL. Ce processus de transfert de paquets vers l’accès partagé nécessite une règle de pare-feu pour autoriser ce paquet DNS entrant, qui est créé par le service HNS lorsque WSL demande initialement à HNS de créer le réseau virtuel NAT pour son conteneur WSL.
En raison de cette conception d’accès partagé NAT, il existe quelques configurations connues qui peuvent empêcher la résolution de noms à partir de WSL.
1. Une entreprise peut envoyer (push) une stratégie qui n’autorise pas les règles de pare-feu définies localement, ce qui autorise uniquement les règles définies par la stratégie d’entreprise.
Lorsqu’elle est définie par une entreprise, la règle de pare-feu créée par HNS est ignorée, car il s’agit d’une règle définie localement. Pour que cette configuration fonctionne, l’entreprise doit créer une règle de pare-feu pour autoriser le port UDP 53 au service d’accès partagé, ou WSL peut être défini pour utiliser le tunneling DNS. Vous pouvez voir s’il est configuré pour ne pas autoriser les règles de pare-feu définies localement en exécutant ce qui suit. Notez que cela affiche les paramètres pour les 3 profils : domaine, privé et public. S’il est défini sur un profil, les paquets sont bloqués si la carte réseau virtuelle WSL est affectée à ce profil (la valeur par défaut est Public). Il s’agit uniquement d’un extrait de code du premier profil de pare-feu retourné dans PowerShell :
PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name : Domain
Enabled : True
DefaultInboundAction : Block
DefaultOutboundAction : Allow
AllowInboundRules : True
AllowLocalFirewallRules : False
AllowLocalFirewallRules:False means the locally defined firewall rules, like that by HNS, will not be applied or used.
2. Et Enterprise peut abaisser la stratégie de groupe et les paramètres de stratégie MDM qui bloquent toutes les règles de trafic entrant.
Ces paramètres remplacent toute règle de pare-feu d’autorisation entrante. Ce paramètre bloque donc la règle de pare-feu UDP créée par HNS et empêche WSL de résoudre les noms. Pour que cette configuration fonctionne, WSL doit être défini pour utiliser le tunneling DNS. Ce paramètre bloque toujours le proxy DNS NAT.
À partir de la stratégie de groupe :
Configuration ordinateur \ Modèles d’administration \ Réseau \ Connexions réseau \ Pare-feu Windows Defender \ Profil de domaine | Profil standard
« Pare-feu Windows Defender : Ne pas autoriser les exceptions » – Activé
À partir de la stratégie MDM :
./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/Shielded
./Vendor/MSFT/Firewall/MdmStore/DomainProfile/Shielded
./Vendor/MSFT/Firewall/MdmStore/PublicProfile/Shielded
Vous pouvez voir s’il est configuré pour ne pas autoriser les règles de pare-feu entrantes en exécutant les instructions suivantes (consultez les mises en garde ci-dessus sur les profils de pare-feu). Il s’agit uniquement d’un extrait de code du premier profil de pare-feu retourné dans PowerShell :
PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name : Domain
Enabled : True
DefaultInboundAction : Block
DefaultOutboundAction : Allow
AllowInboundRules : False
AllowInboundRules: False means that no inbound Firewall rules will be applied.
3. Un utilisateur passe par les applications de paramètre Sécurité Windows et coche le contrôle « Bloque toutes les connexions entrantes, y compris celles figurant dans la liste des applications autorisées ».
Windows prend en charge un consentement utilisateur pour le même paramètre qui peut être appliqué par une entreprise référencée au point 2 ci-dessus. Les utilisateurs peuvent ouvrir la page de paramètres « Sécurité Windows », sélectionner l’option « Pare-feu et protection réseau », sélectionner le profil de pare-feu qu’ils souhaitent configurer (domaine, privé ou public) et, sous « Connexions entrantes » , vérifiez que le contrôle intitulé « Bloque toutes les connexions entrantes, y compris celles figurant dans la liste des applications autorisées. »
Si ce profil est défini pour le profil public (il s’agit du profil par défaut pour la carte réseau virtuelle WSL), la règle de pare-feu créée par HNS pour autoriser les paquets UDP à l’accès partagé sera bloquée.
Cela ne doit pas être sélectionné pour que la configuration du proxy DNS NAT fonctionne à partir de WSL, ou WSL peut être défini pour utiliser le tunneling DNS.
4. La règle de pare-feu HNS pour autoriser les paquets DNS à l’accès partagé peut devenir non valide, référençant un identificateur d’interface WSL précédent. Il s’agit d’une faille dans HNS qui a été corrigée avec la dernière version de Windows 11. Dans les versions antérieures, si cela se produit, ce n’est pas facilement détectable, mais il existe une solution de contournement :
Arrêter WSL
wsl.exe –shutdown
Supprimez l’ancienne règle de pare-feu HNS. Cette commande PowerShell doit fonctionner dans la plupart des cas :
Get-NetFirewallRule -Name "HNS*" | Get-NetFirewallPortFilter | where Protocol -eq UDP | where LocalPort -eq 53 | Remove-NetFirewallRule
Supprimez tous les points de terminaison HNS. Remarque : si HNS est utilisé pour gérer d’autres conteneurs, tels que MDAG ou Bac à sable Windows, ceux-ci doivent également être arrêtés.
hnsdiag.exe delete all
Redémarrer la machine ou redémarrer le service HNS
Restart-Service hns
Lorsque WSL est redémarré, HNS crée des règles de pare-feu, ciblant correctement l’interface WSL.
Si vous n’avez aucun accès réseau, cela peut être dû à une mauvaise configuration. Vérifiez si le pilote FSE est en cours d’exécution : ‘sc queryex FSE’. Si ce n’est pas le cas, vérifiez si la valeur de Registre PortTrackerEnabledMode s’arrête sous cette clé de Registre : reg query HKLM\System\CurrentControlSet\Services\Tcpip\Parameters. Si FSE n’est pas en cours d’exécution ou n’est pas installé et que PortTrackerEnabledMode existe, supprimez cette valeur de Registre et redémarrez
Les adaptateurs fantômes, ou les appareils fantômes Plug-and-Play (PnP), font référence aux composants matériels qui apparaissent dans votre système, mais qui ne sont pas connectés physiquement. Ces appareils « fantômes » peuvent entraîner une confusion et un encombrement dans vos paramètres système. Si vous voyez des adaptateurs fantômes lors de l’exécution de WSL dans une machine virtuelle, suivez ces étapes manuelles pour rechercher et supprimer ces appareils Fantôme PnP. Microsoft travaille sur une solution automatisée qui ne nécessite pas d’intervention manuelle. Plus d’informations seront bientôt disponibles.
Suivez les instructions pour collecter les journaux WSL dans le référentiel WSL sur GitHub pour récupérer des journaux détaillés et signaler un problème sur notre plateforme GitHub.
Deux composants du sous-système Windows pour Linux peuvent nécessiter une mise à jour.
Pour mettre à jour le sous-système Windows pour Linux lui-même, utilisez la commande wsl --update
dans PowerShell ou CMD.
Pour mettre à jour les fichiers binaires utilisateur de distributions Linux spécifiques, utilisez la commande apt-get update | apt-get upgrade
dans la distribution Linux que vous cherchez à mettre à jour.
Certains packages utilisent des fonctionnalités que nous n’avons pas encore implémentées. udev
, par exemple, n’est pas encore pris en charge et provoque plusieurs erreurs avec apt-get upgrade
.
Pour résoudre les problèmes liés à udev
, procédez comme suit :
Écrivez le code suivant dans /usr/sbin/policy-rc.d
et enregistrez vos modifications.
#!/bin/sh
exit 101
Ajoutez des autorisations d’exécution à /usr/sbin/policy-rc.d
:
chmod +x /usr/sbin/policy-rc.d
Exécutez les commandes suivantes :
dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl
Cette erreur est due au fait que nous ne prenons pas en charge la console héritée. Pour désactiver la console héritée :
La fonctionnalité de sous-système Windows pour Linux peut être désactivée au cours d’une mise à jour de Windows. Dans ce cas, la fonctionnalité Windows doit être réactivée. Pour obtenir des instructions sur l’activation du sous-système Windows pour Linux, consultez le guide d’installation manuelle.
Le processus d’installation de WSL tente de changer automatiquement les paramètres régionaux d’Ubuntu de sorte qu’ils correspondent à ceux de votre installation Windows. Si vous souhaitez éviter ce comportement, vous pouvez exécuter cette commande pour changer les paramètres régionaux d’Ubuntu une fois l’installation terminée. Vous devrez relancer bash.exe pour que ce changement prenne effet.
L’exemple ci-dessous applique les paramètres régionaux en-US
:
sudo update-locale LANG=en_US.UTF8
%windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux
. Certains utilisateurs ont signalé des problèmes posés par certaines applications de pare-feu, qui bloquent l’accès Internet dans WSL. Les pare-feux signalés sont :
Dans certains cas, la désactivation du pare-feu permet d’obtenir l’accès. Parfois, il semble que la simple installation du pare-feu bloque l’accès.
Si vous utilisez le pare-feu Microsoft Defender et que vous décochez la case « Bloquer toutes les connexions entrantes, y compris celles figurant dans la liste des applications autorisées », l’accès est autorisé.
Pour la Mise à jour anniversaire Windows, version 1607, les privilèges administrateur dans Windows doivent exécuter la commande ping dans WSL. Pour exécuter une commande ping, exécutez Bash sur Ubuntu sur Windows en tant qu’administrateur, ou exécutez bash.exe à partir d’une invite de commandes/PowerShell avec des privilèges d’administrateur.
Pour les versions ultérieures de Windows, Build 14926+, les privilèges administrateur ne sont plus nécessaires.
Si, alors que vous utilisez Bash, celui-ci se bloque et ne répond pas aux entrées, aidez-nous à diagnostiquer le problème en collectant une image mémoire et en nous la communiquant. Notez que la procédure ci-après entraînera le plantage de votre système. Suivez-la uniquement si vous êtes à l’aise avec ce type d’opération, ou enregistrez votre travail au préalable.
Pour collecter une image mémoire
Changez le type d’image mémoire en choisissant « Image mémoire complète ». Lors de ce changement, prenez note du type d’image actuel.
Suivez cette procédure pour configurer une commande de clavier produisant un plantage.
Reproduisez le blocage.
Faites planter le système à l’aide de la séquence de touches définie à l’étape 2.
Le système plante et collecte l’image mémoire.
Une fois le système redémarré, envoyez l’image memory.dmp sur secure@microsoft.com. L’emplacement par défaut du fichier d’image mémoire est %SystemRoot%\memory.dmp ou C:\Windows\memory.dmp si C: est le lecteur système. Dans l’e-mail, indiquez que le fichier d’image mémoire est destiné à l’équipe WSL ou Bash sur Windows.
Rétablissez le type d’image mémoire d’origine.
Pour trouver le numéro de build de Windows et de l’architecture de votre PC, sélectionnez :
Paramètres>Système>À propos
Recherchez les champs Build du système d’exploitation et Type de système.
Pour trouver le numéro de build de Windows Server, exécutez la commande suivante dans PowerShell :
systeminfo | Select-String "^OS Name","^OS Version"
Vous pouvez vérifier que le Sous-système Windows pour Linux est activé en exécutant la commande suivante dans une fenêtre PowerShell avec privilèges élevés :
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
L’erreur suivante se produit lors d’une tentative de connexion du serveur SSH : « Connection closed by 127.0.0.1 port 22 » (Connexion fermée par 127.0.0.1 port 22).
Vérifiez que votre serveur OpenSSH est en cours d’exécution :
sudo service ssh status
et veillez à suivre ce tutoriel : https://ubuntu.com/server/docs/service-openssh
Arrêtez le service SSHD et démarrez SSHD en mode débogage :
sudo service ssh stop
sudo /usr/sbin/sshd -d
Consultez les journaux de démarrage et vérifiez que les clés d’hôte sont disponibles et que les journaux ne contiennent pas de message de ce type :
debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: key_load_private: incorrect passphrase supplied to decrypt private key
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_rsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_dsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_ed25519_key
Si vous voyez des messages de ce type et que les clés ne sont pas disponibles sous /etc/ssh/
, vous devrez régénérer les clés ou simplement purger et installer le serveur OpenSSH :
sudo apt-get purge openssh-server
sudo apt-get install openssh-server
Cette erreur est liée à un mauvais état d’installation. Effectuez les étapes suivantes pour essayer de résoudre ce problème :
Si vous exécutez la commande d’activation de la fonctionnalité WSL à partir de PowerShell, essayez d’utiliser l’interface GUI au lieu d’ouvrir le menu Démarrer, recherchez « Activer ou désactiver les fonctionnalités Windows », puis dans la liste, sélectionnez « Sous-système Windows pour Linux » qui installera le composant facultatif.
Mettez à jour votre version de Windows en accédant à Paramètres, Mises à jour, puis en cliquant sur « Rechercher les mises à jour ».
Si les deux échouent et que vous devez accéder à WSL, procédez à une mise à niveau sur place en réinstallant Windows avec un support d’installation et en sélectionnant « Tout conserver » pour vous assurer que vos applications et vos fichiers sont conservés. Vous trouverez des instructions pour ce faire dans la page Réinstaller Windows 10.
Si vous voyez cette erreur :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/user/.ssh/private-key.pem' are too open.
Pour la corriger, ajoutez ce qui suit au fichier /etc/wsl.conf
:
[automount]
enabled = true
options = metadata,uid=1000,gid=1000,umask=0022
Veuillez noter que l’ajout de cette commande inclura les métadonnées et modifiera les autorisations sur les fichiers Windows vus depuis WSL. Pour plus d’informations, consultez Autorisations de système de fichier.
Si vous utilisez openssh-server sur windows et tessayez d’accéder à WSL à distance, vous risquez de voir cette erreur :
The file cannot be accessed by the system.
Il s’agit d’un problème connu lors de l’utilisation de la version Store de WSL. Vous pouvez contourner ce problème aujourd’hui à l’aide de WSL 1 ou de la version Windows de WSL. Pour plus d'informations, consultez https://aka.ms/wslstoreinfo.
Certaines distributions disponibles dans le Microsoft Store ne sont pas encore entièrement compatibles pour exécuter des commandes Windows prêtes à l’emploi. Si vous recevez une erreur -bash: powershell.exe: command not found
en exécutant powershell.exe /c start .
ou une autre commande Windows, vous pouvez la résoudre en suivant ces étapes :
echo $PATH
./mnt/c/Windows/system32
, quelque chose redéfinit la variable PATH standard.cat /etc/profile
.cat /etc/wsl.conf
et assurez-vous qu’il ne contient pas appendWindowsPath=false
; sinon, mettez-le en commentaire.wsl -t
suivi du nom de la distribution ou exécutez wsl --shutdown
dans cmd ou PowerShell.Nous avons connaissance d’un problème qui empêche les utilisateurs de démarrer après avoir installé WSL 2. Alors que nous procédons au diagnostic complet de ce problème, les utilisateurs ont signalé que le changement de la taille de la mémoire tampon ou l’installation des pilotes appropriés peut aider à le résoudre. Veuillez consulter ce problème GitHub pour voir les dernières informations le concernant.
Le partage de connexion Internet (ICS) est un composant obligatoire de WSL 2. Le service ICS est utilisé par le service de réseau hôte (HNS) pour créer le réseau virtuel sous-jacent sur lequel WSL 2 s’appuie pour NAT, DNS, DHCP et le partage de connexion hôte.
La désactivation du service ICS (SharedAccess) ou la désactivation du partage de connexion Internet via la stratégie de groupe empêche la création du réseau HNS WSL. Cela entraîne des échecs lors de la création d’une image WSL version 2 ainsi que l’erreur suivante lors de la tentative de conversion d’une image de version 1 vers la version 2.
There are no more endpoints available from the endpoint mapper.
Les systèmes qui requièrent WSL 2 doivent conserver le service ICS (SharedAccess) dans son état de démarrage par défaut, Manuel (Déclencher le démarrage), et toute stratégie qui désactive le partage de connexion Internet doit être remplacée ou supprimée. Alors que la désactivation du service ICS arrête WSL 2 et que nous ne la recommandons pas, certaines parties d’ICS peuvent être désactivées en suivant ces instructions.
Il existe plusieurs différences à noter si vous exécutez une version antérieure de Windows et WSL, comme Windows 10 Creators Update (oct 2017, build 16299) ou Mise à jour anniversaire Windows 10 (août 2016, build 14393). Nous vous recommandons d’effectuer la mise à jour vers la dernière version de Windows mais, si cela n’est pas possible, nous avons décrit certaines des différences ci-dessous.
Différences entre les commandes d’interopérabilité :
bash.exe
a été remplacé par wsl.exe
. Les commandes Linux peuvent être exécutées à partir de l’invite de commandes Windows ou de PowerShell, mais pour les versions antérieures de Windows, vous pouvez être amené à utiliser la commande bash
. Par exemple : C:\temp> bash -c "ls -la"
. Les commandes WSL passées à bash -c
sont transmises au processus WSL sans modification. Les chemins de fichiers doivent être spécifiés au format WSL et des précautions doivent être prises pour placer les caractères appropriés dans une séquence d’échappement. Par exemple, C:\temp> bash -c "ls -la /proc/cpuinfo"
ou C:\temp> bash -c "ls -la \"/mnt/c/Program Files\""
.[distro.exe] /?
. Par exemple, avec Ubuntu : C:\> ubuntu.exe /?
.$PATH
./mnt/c/Windows/System32/notepad.exe
root
, utilisez la commande C:\> lxrun /setdefaultuser root
dans PowerShell, puis exécutez Bash.exe pour vous connecter : C:\> bash.exe
. Réinitialisez votre mot de passe à l’aide de la commande de mot de passe de la distribution $ passwd username
, puis fermez la ligne de commande Linux avec $ exit
. À partir de l’invite de commandes Windows ou de Powershell, réinitialisez l’utilisateur par défaut sur votre compte d’utilisateur Linux normal : C:\> lxrun.exe /setdefaultuser username
.Si vous avez à l’origine installé WSL sur une version de Windows 10 antérieure à Creators Update (oct 2017, build 16299), nous vous recommandons de migrer les fichiers, les données, etc. nécessaires de l’ancienne distribution Linux installée vers une distribution plus récente installée via le Microsoft Store. Pour supprimer la distribution héritée de votre ordinateur, exécutez la commande suivante à partir d’une ligne de commande ou d’une instance PowerShell : wsl --unregister Legacy
. Vous avez également la possibilité de retirer manuellement l’ancienne distribution héritée en supprimant le dossier %localappdata%\lxss\
(et son sous-contenu) à l’aide de l’Explorateur de fichiers Windows ou de PowerShell : rm -Recurse $env:localappdata/lxss/
.
Commentaires sur Windows Subsystem for Linux
Windows Subsystem for Linux est un projet open source. Sélectionnez un lien pour fournir des commentaires :
Entrainement
Parcours d’apprentissage
Configurer la mise en réseau sur Windows clients - Training
MD-100 Configurer la mise en réseau sur Windows clients