Не удается выполнить ping хоста Windows из WSL2.

Вопрос или проблема

Я активировал WSL2 на своем настольном компьютере с Windows 10. До недавнего времени я мог подключаться к приложениям, установленным на хосте, из WSL2. Однако сейчас, для тестирования, когда я пингую хост, я получаю сообщение “Destination Host Unreachable”.

Интересное наблюдение заключается в том, что после перезапуска WSL2 из PowerShell

Get-Service LxssManager | Restart-Service

и быстрого пинга HOST в командной строке WSL, я вижу успешные ответы на начальные запросы, но в конечном итоге хост становится недоступным.

user@MACHINEM5D:/mnt/c/windows/system32$ ping host.docker.internal
PING host.docker.internal (192.168.29.99) 56(84) bytes of data.
64 bytes from host.docker.internal (192.168.29.99): icmp_seq=1 ttl=127 time=0.772 ms
64 bytes from host.docker.internal (192.168.29.99): icmp_seq=2 ttl=127 time=0.676 ms
From 192.168.16.1 (192.168.16.1) icmp_seq=3 Destination Host Unreachable
From 192.168.16.1 (192.168.16.1) icmp_seq=4 Destination Host Unreachable
From 192.168.16.1 (192.168.16.1) icmp_seq=5 Destination Host Unreachable

Кроме того, из WSL2 я могу выходить в интернет.

user@MACHINEM5D:/mnt/c/windows/system32$ cat /etc/resolv.conf
nameserver 8.8.8.8

user@MACHINEM5D:/mnt/c/windows/system32$ ping google.com
PING google.com (172.217.167.206) 56(84) bytes of data.
64 bytes from del03s18-in-f14.1e100.net (172.217.167.206): icmp_seq=1 ttl=117 time=104 ms
64 bytes from del03s18-in-f14.1e100.net (172.217.167.206): icmp_seq=2 ttl=117 time=105 ms
64 bytes from del03s18-in-f14.1e100.net (172.217.167.206): icmp_seq=3 ttl=117 time=109 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

В файле hosts Windows есть следующие записи

# разрешение имени localhost обрабатывается внутри DNS.
127.0.0.1       localhost
::1             localhost
# Добавлено Docker Desktop
192.168.29.99 host.docker.internal
192.168.29.99 gateway.docker.internal
# Чтобы один и тот же kube-контекст работал на хосте и в контейнере:
127.0.0.1 kubernetes.docker.internal
# Конец раздела

Вывод /etc/hosts в WSL2.

user@MACHINEM5D:/mnt/c/windows/system32$ cat /etc/hosts
# Этот файл был автоматически сгенерирован WSL. Чтобы остановить автоматическую генерацию этого файла, добавьте следующую запись в /etc/wsl.conf:
# [network]
# generateHosts = false
127.0.0.1       localhost
127.0.1.1       INNOXXXXXX5D.XXX.XXX.XXX

127.0.0.1       localhost
::1     localhost
192.168.29.99   host.docker.internal
192.168.29.99   gateway.docker.internal
127.0.0.1       kubernetes.docker.internal

# Следующие строки рекомендуются для хостов с поддержкой IPv6
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Что-то, что я также проверил, это то, что я могу пинговать IP адрес eth0 WSL2 с хоста Windows.

C:\Users\XXXX27>ping 172.18.81.68

Pinging 172.18.81.68 with 32 bytes of data:
Reply from 172.18.81.68: bytes=32 time<1ms TTL=64
Reply from 172.18.81.68: bytes=32 time<1ms TTL=64
Reply from 172.18.81.68: bytes=32 time<1ms TTL=64
Reply from 172.18.81.68: bytes=32 time<1ms TTL=64

Ping statistics for 172.18.81.68:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Что-то, что раньше работало, это доступ к MYSQL, установленному на хосте Windows, из WSL2. Это перестало работать.

user@MACHINEM5D:/mnt/c/windows/system32$ mysql -u auth_user -p teamup_auth -h 192.168.29.99
Enter password:
ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.29.99:3306' (113)

Вы пытаетесь использовать сетевое имя, специфичное для Docker Desktop. Не используйте это имя, если не работаете с Docker Desktop. Оно может быть доступно по техническим причинам, пока работает Docker Desktop, но вы все равно не должны использовать его в других случаях.

Вместо этого следуйте рекомендуемому Microsoft способу и получите внутренний IP-адрес хоста из resolv.conf:

grep "nameserver" /etc/resolv.conf | awk '{print $2}'

Хорошо известное псевдоним имени хоста по умолчанию не существует. Вы можете использовать pcname.local, где pcname — это имя вашей сети ПК. Не забывайте добавлять .local.

Кроме того, имейте в виду, что реальный доступ (за пределами пинга) будет проблематичным, потому что, с точки зрения брандмауэра Windows, сеть WSL является “Общей”. Будут применяться другие, более строгие правила брандмауэра. Поскольку сеть WSL несколько скрыта, вы не получите всплывающее окно “Разрешить это приложение”. Вам нужно будет использовать расширенную конфигурацию брандмауэра, чтобы вручную включить или создать необходимые правила.


WSL 2 по умолчанию не использует адреса в 192.168/16. Вместо этого при каждом запуске он выбирает случайную подсеть из 172.16/12.

Ответ или решение

Проблема: Невозможность пинга Windows хоста из WSL2

Ваша проблема с невозможностью пинга хоста Windows из WSL2 может быть вызвана несколькими факторами, включая сетевые настройки, политики брандмауэра и конфигурацию WSL2. Давайте подробно рассмотрим возможные причины и пути их решения.

1. Проверка конфигурации WSL2 и сетевых настроек

WSL2 работает в виртуализированном окружении и, как следствие, имеет собственную сетевую конфигурацию. Ваша наблюдаемая проблема, когда пинг успешен только после перезапуска WSL2, может указывать на проблемы с маршрутизацией или конфликт IP-адресов.

Шаги для проверки:
  • Проверьте IP-адрес WSL2. Используйте команду ip addr в WSL2, чтобы получить IP-адрес интерфейса eth0. Убедитесь, что этот адрес не конфликтует с другими устройствами в вашей сети.
  • Проверьте конфигурацию сетевых шлюзов. Убедитесь, что WSL2 правильно настроен на использование вашего локального сетевого подключения.

2. Использование правильных адресов и имен

Логирование использования host.docker.internal для доступа к хосту может не всегда работать, особенно если Docker Desktop не запущен. Вместо этого используйте следующую команду для получения IP-адреса хоста:

grep "nameserver" /etc/resolv.conf | awk '{print $2}'

Также проверьте, что имя вашего компьютера правильно настроено, и попробуйте использовать его с добавлением .local.

3. Настройка брандмауэра Windows

Проблема может быть связана с настройками брандмауэра Windows, который может блокировать трафик между WSL2 и хостом.

Шаги для настройки брандмауэра:
  • Откройте Панель управления и перейдите в раздел "Система и безопасность" -> "Брандмауэр Windows".
  • Нажмите на "Дополнительные параметры" и добавьте новые правила для разрешения входящих подключений на порты, которые вы используете (например, 3306 для MySQL).
  • Убедитесь, что брандмауэр не блокирует трафик для частной и общедоступной сетей.

4. Детерминированный доступ к MySQL

Вы упомянули, что не можете подключиться к MySQL, установленному на Windows, используя команду:

mysql -u auth_user -p teamup_auth -h 192.168.29.99

Убедитесь, что MySQL настроен для прослушивания на всех интерфейсах. Проверьте файл конфигурации MySQL (обычно my.cnf) и убедитесь, что строка:

bind-address = 0.0.0.0

Тогда база данных будет принимать подключения с любых IP-адресов.

5. Предельный доступ к приложениям

Имейте в виду, что ограниченный доступ может касаться не только MySQL, но и других приложений, запущенных на Windows. Поскольку WSL2 используется как частная сеть, некоторые приложения на хосте могут не предоставлять доступ из-за более строгих правил безопасности или настройки брандмауэра.

Заключение

Если вы следовали всем перечисленным шагам и проблема все равно сохраняется, возможно, стоит переустановить WSL2 или Docker Desktop, чтобы убедиться, что конфигурации не повреждены. Изучение журнала событий Windows может также дать подсказки о том, что блокирует соединение. Если вам нужно больше информации или помощь, всегдa обращайтесь за поддержкой к сообществу WSL или Docker.

Таким образом, следуя данным рекомендациям, вы сможете восстановить доступ к ресурсам Windows из WSL2 и продолжить полноценную работу в вашей среде разработки.

Оцените материал
Добавить комментарий

Капча загружается...