Доступ к сетевым приложениям с помощью WSL

  • Статья

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

Сетевой режим по умолчанию: NAT

По умолчанию WSL использует архитектуру на основе NAT (преобразование сетевых адресов) для сети. При работе с сетевой архитектурой на основе NAT следует учитывать следующие рекомендации.

Доступ к сетевым приложениям Linux из Windows (localhost)

Если вы создаете сетевое приложение (например, приложение, работающее на NodeJS или SQL Server) в дистрибутиве Linux, вы можете получить к нему доступ из приложения Windows (например, используя Microsoft Edge или Chrome) с помощью localhost (как обычно это и происходит).

Доступ к сетевым приложениям Windows из Linux (IP-адрес основной системы)

Если вы хотите получить доступ к сетевому приложению, работающему в Windows (например, к приложению, работающему на NodeJS или SQL Server) из дистрибутива Linux (напр., Ubuntu), необходимо использовать IP-адрес основной системы. Хотя это происходит и нечасто, для этого можно выполнить следующие действия.

  1. Получите IP-адрес основной системы, выполнив следующую команду из дистрибутива Linux: ip route show | grep -i default | awk '{ print $3}'
  2. Подключитесь к любому серверу Windows, используя скопированный IP-адрес.

На изображении ниже показан пример подключения к серверу Node.js под управлением Windows через cURL.

Подключение к серверу NodeJS в Windows с помощью cURL

Подключение через удаленные IP-адреса

При использовании удаленных IP-адресов для подключения к приложениям они будут рассматриваться как подключения из локальной сети (LAN). Это означает, что необходимо убедиться, что приложение может принимать подключения по локальной сети.

Например, может потребоваться привязать приложение к 0.0.0.0 вместо 127.0.0.1. В примере приложения Python, использующего Flask, это можно сделать с помощью команды app.run(host='0.0.0.0'). Помните о безопасности при внесении этих изменений, так как это позволит подключениям из локальной сети.

Доступ к дистрибутиву WSL 2 из локальной сети (LAN)

При использовании дистрибутива WSL 1, если к компьютеру можно получить доступ из локальной сети, то приложения, работающие в WSL, могут быть также доступны в локальной сети.

Это нетипичная ситуация в WSL 2. В WSL 2 имеется виртуализированный адаптер Ethernet с собственным уникальным IP-адресом. В настоящее время для включения этого рабочего процесса необходимо выполнить те же действия, что и для обычной виртуальной машины. (Мы ищем способы улучшить это взаимодействие.)

Ниже приведен пример использования команды Portproxy интерфейса Netsh для добавления прокси-сервера порта, прослушивающего порт узла и подключающего прокси-сервер порта к IP-адресу виртуальной машины WSL 2.

netsh interface portproxy add v4tov4 listenport=<yourPortToForward> listenaddress=0.0.0.0 connectport=<yourPortToConnectToInWSL> connectaddress=(wsl hostname -I)

В этом примере необходимо обновить <yourPortToForward> номер порта, например listenport=4000. listenaddress=0.0.0.0 означает, что входящие запросы будут приниматься из ЛЮБОГО IP-адреса. Адрес прослушивания указывает IPv4-адрес, для которого требуется прослушивать и может быть изменен на значения, которые включают IP-адрес, имя netBIOS компьютера или DNS-имя компьютера. Если адрес не указан, по умолчанию используется адрес локального компьютера. Необходимо обновить <yourPortToConnectToInWSL> значение до номера порта, в котором требуется подключиться WSL, например connectport=4000. Наконец, значение должно быть IP-адресом дистрибутива Linux, connectaddress установленным через WSL 2 (адрес виртуальной машины WSL 2), который можно найти, введя команду: wsl.exe hostname -I

Поэтому эта команда может выглядеть примерно так:

netsh interface portproxy add v4tov4 listenport=4000 listenaddress=0.0.0.0 connectport=4000 connectaddress=192.168.101.100

Чтобы получить IP-адрес, используйте следующую команду:

  • wsl hostname -I для IP-адреса дистрибутива Linux, установленного через WSL 2 (адрес виртуальной машины WSL 2)
  • cat /etc/resolv.conf для IP-адреса компьютера Windows, как показано на виртуальной машине WSL 2 (виртуальная машина WSL 2)

Использование listenaddress=0.0.0.0 будет прослушивать все порты IPv4.

Примечание.

Использование нижнего регистра "i" с командой имени узла приведет к созданию другого результата, отличного от использования верхнего регистра "I". wsl hostname -i — это локальный компьютер (127.0.1.1 — это адрес диагностики заполнителя), а wsl hostname -I IP-адрес локального компьютера будет возвращен другими компьютерами и должен использоваться для идентификации connectaddress дистрибутива Linux, работающего через WSL 2.

Доступ по протоколу IPv6

  • wsl hostname -i для IP-адреса дистрибутива Linux, установленного через WSL 2 (адрес виртуальной машины WSL 2)
  • ip route show | grep -i default | awk '{ print $3}' для IP-адреса компьютера Windows, как показано на виртуальной машине WSL 2 (виртуальная машина WSL 2)

Использование listenaddress=0.0.0.0 будет прослушивать все порты IPv4.

Зеркальное отображение сети

Вы можете задать networkingMode=mirrored в [wsl2] файле, .wslconfig чтобы включить зеркало сети в режиме зеркало. Включив это изменение WSL в совершенно новую сетевую архитектуру, которая имеет цель "зеркало" сетевых интерфейсов, имеющихся в Windows в Linux, для добавления новых сетевых функций и повышения совместимости.

Ниже приведены текущие преимущества включения этого режима:

  • Поддержка протокола IPv6
  • Подключение на серверы Windows из Linux с помощью адреса 127.0.0.1localhost. Адрес ::1 локального узла IPv6 не поддерживается
  • Улучшена совместимость сети для виртуальных сетей
  • Поддержка многоадресной рассылки
  • Подключение в WSL непосредственно из локальной сети (LAN)

Примечание.

Выполните следующую команду в окне PowerShell с правами администратора, чтобы настроить параметры брандмауэра Hyper-V, чтобы разрешить входящий трафик: Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow илиNew-NetFirewallHyperVRule -Name "MyWebServer" -DisplayName "My Web Server" -Direction Inbound -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -Protocol TCP -LocalPorts 80.

Этот новый режим устраняет проблемы с сетью, возникающие при использовании архитектуры на основе NAT (преобразование сетевых адресов). Найдите известные проблемы или отзывы о любых ошибках, обнаруженных в репозитории продукта WSL на GitHub.

Туннелирование DNS

[wsl2] Если параметрdnsTunneling=trueв .wslconfig файле содержит WSL, используйте функцию виртуализации, чтобы ответить на ЗАПРОСы DNS из WSL, а не запрашивать их по сетевому пакету. Эта функция предназначена для улучшения совместимости с виртуальными сетями и других сложных сетей.

Автоматический прокси-сервер

[wsl2] Параметр autoProxy=true в файле применяет WSL для использования сведений о прокси-сервере .wslconfig HTTP Windows. Если у вас уже настроен прокси-сервер в Windows, включение этой функции приведет к автоматическому настройке прокси-сервера в WSL.

WSL и брандмауэр

На компьютерах под управлением Windows 11 22H2 и более поздних версий с WSL 2.0.9 и выше функция брандмауэра Hyper-V будет включена по умолчанию. Это обеспечит следующее: