3 votes

L'application Ubuntu pour Windows reçoit sporadiquement une erreur "Échec temporaire de la résolution du nom".

J'ai l'application Ubuntu pour Windows (téléchargée depuis le Microsoft Store) et je reçois constamment une erreur de résolution de nom temporaire.

ping: google.com: Résolution temporaire du nom en échec

Cela se produit à la fois lorsque je suis connecté à un VPN et lorsque je ne le suis pas. Cependant, si j'exécute la commande :

echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf

Alors cela résout le problème quand je ne suis pas connecté au VPN. Cependant, même après avoir exécuté la commande, cela ne fonctionne toujours pas si je suis connecté au VPN.

J'ai besoin de me connecter à un serveur distant via ssh ce qui nécessite que je sois sur le VPN pour y accéder. Par conséquent, je dois déterminer pourquoi lorsque je suis connecté au VPN la résolution des noms ne se produit pas. Il serait également préférable de résoudre le problème de manière permanente même lorsque je ne suis pas connecté au VPN pour ne pas avoir à exécuter la commande ci-dessus à chaque fois.

Voici à quoi ressemble le fichier /etc/resolv.conf (avant d'exécuter la commande ci-dessus) :

# Ce fichier a été généré automatiquement par WSL. Pour arrêter la génération automatique de ce fichier, ajoutez l'entrée suivante à /etc/wsl.conf :
# [network]
# generateResolvConf = false
nameserver 172.22.96.1

Je vous remercie pour vos idées!

5voto

NotTheDr01ds Points 5135

J'ai besoin de me connecter à un serveur distant via ssh qui nécessite que je sois sur le VPN pour y accéder.

Pour ce cas d'utilisation particulier, au moins, la solution devrait (espérons-le) être assez simple - Créez une instance WSL1 au lieu de WSL2.

Le réseau de WSL2 est virtualisé et NAT'd derrière (à l'intérieur) de la machine Windows. Normalement, lorsque WSL2 démarre, le processus /init crée un resolv.conf qui pointe vers une adresse IP sur la machine Windows, et un processus sur la machine Windows agit comme un résolveur proxy.

Bien que je ne sache pas exactement pourquoi le vôtre échoue lorsque vous n'êtes pas connecté au VPN, je sais que WSL2 a des problèmes importants lorsqu'il est connecté via de nombreux types de VPN. Certains VPN (en particulier d'entreprise) bloqueront tout le trafic local lorsqu'ils sont connectés. Par exemple, si vous avez un autre ordinateur ou une imprimante sur votre réseau local, vous n'êtes probablement pas en mesure d'y accéder non plus lorsque vous êtes connecté au VPN. Et comme WSL2 apparaît à Windows comme "un autre ordinateur" (en quelque sorte), il bloque également l'accès. Pour cette raison, le résolveur ne fonctionnera pas lorsque vous êtes connecté à de nombreux VPN.

WSL1, en revanche, n'a pas ce problème. Il partage (un "pont" en quelque sorte) l'interface réseau avec Windows.

Et comme ssh fonctionne très bien sous WSL1, c'est probablement la meilleure option.

Vous pouvez soit convertir soit copier la distribution WSL2 existante vers WSL1. Dans les deux cas, commencez par faire une sauvegarde. Depuis PowerShell:

wsl -l -v
# Confirmez le nom de la distribution et 
# ajustez les commandes suivantes si nécessaire
wsl --export  ubuntu_backup.tar

Pour convertir:

wsl --set-version  1

Pour copier:

mkdir 
wsl --import Ubuntu_WSL1  /ubuntu.tar --version 1

Autres possibilités

Je n'ai pas testé cela moi-même, mais si vous êtes sur Windows 11 Professionnel (ou Éducation) ou supérieur, il existe une version Preview de WSL disponible dans le Microsoft Store. Cette version dispose actuellement d'une nouvelle fonctionnalité qui vous permet de créer un commutateur réseau Hyper-V en pont et de l'utiliser dans WSL2.

Cela peut vous permettre d'utiliser WSL2 tout en étant connecté au VPN.

Voir ce post Reddit pour plus de détails.

Mais vraiment, je resterais avec WSL1 dans ce cas. Je garde à la fois des instances WSL2 et WSL1 pour cette raison précise (et d'autres où WSL1 a encore des avantages par rapport à WSL2).

0voto

johncgl Points 1

Utiliser WSL1 comme @NotTheDr01ds suggère est probablement la solution la plus simple si c'est une option pour vous.

Votre problème pourrait être dû à l'implémentation réseau de WSL2, provoquant que son trafic ressemble à un réseau local plutôt qu'à un hôte local vers l'adaptateur VPN :

[...] Nous voulons que tout le trafic passe par le VPN lorsque le VPN est activé. Le seul problème est que le VPN ne transfère le trafic que de l'ORDINATEUR LOCAL, et le trafic provenant de WSL 2 N'EST PAS considéré comme provenant de votre ordinateur local. Le pilote VPN le considère comme un réseau local. Allez comprendre !

C'est donc notre problème en un mot : chaque fois que votre VPN se connecte, il ajoute une règle de haute priorité à la table de routage pour WSL 2. Cette route dirigera tout le trafic de WSL 2 directement vers l'adaptateur virtuel du VPN. L'adaptateur l'accepte joyeusement puis le laisse tomber dans un trou noir, tuant efficacement tout le trafic réseau.

La solution varie de plutôt complexe à très complexe (je ne l'ai pas encore résolue moi-même).

Le point de départ est :

Génial ! Quel est le correctif? Facile. Nous supprimons la route de priorité ajoutée par le VPN.

Une fois supprimée, le routage va se reposer sur les deux autres règles de priorité inférieure et acheminer tout le trafic de WSL 2 vers l'hôte Windows. Une fois là-bas, il circulera à travers le VPN comme d'habitude.

Étapes détaillées sur comment l'auteur a atteint cela. Notez qu'ils ont 3 articles sur le problème.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X