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

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

Определение IP-адреса

Существует два сценария, которые следует учитывать при определении IP-адреса, используемого для дистрибутива Linux, работающего через WSL:

сценарий один: С точки зрения узла Windows вы хотите запросить IP-адрес дистрибутива Linux, работающий через WSL2, чтобы программа на узле Windows может подключаться к серверной программе, работающей внутри дистрибутива (экземпляр).

Хост Windows может использовать команду:

wsl.exe --distribution <DistroName> hostname -i

При запросе распределения по умолчанию эта часть команды, назначающая распределение, может быть опущена: -d <DistroName>. Не забудьте использовать флаг -i в нижнем регистре.

Под капотом хост-команда wsl.exe запускает целевой экземпляр и выполняет команду hostname --ip-addresses Linux. Затем эта команда отображает IP-адрес экземпляра WSL в STDOUT. Затем STDOUT текстовое содержимое передается обратно в wsl.exe. Наконец, wsl.exe отображает выходные данные в командной строке.

Типичные выходные данные могут быть:

172.30.98.229

Сценарий два: программа, запущенная внутри дистрибутива Linux через WSL2 (экземпляр), хочет знать IP-адрес узла Windows, чтобы программа Linux могла подключиться к программе сервера узла Windows.

Пользователь WSL2 Linux может использовать команду:

ip route show | grep -i default | awk '{ print $3}'

Типичные выходные данные могут быть:

172.30.96.1

Таким образом, 172.30.96.1 является IP-адресом узла для Windows в этом примере.

Заметка

Эти действия, описанные выше, требуются при выполнении WSL2 с сетевом режиме NAT по умолчанию. При запуске WSL2 с новым зеркальным режимом, хост Windows и виртуальная машина WSL2 могут подключаться друг к другу, используя localhost (127.0.0.1) в качестве целевого адреса, поэтому трюк с использованием IP-адреса однорангового узла не требуется.

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

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

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

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

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

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

1. Получите IP-адрес хост-компьютера, выполнив следующую команду из дистрибутива Linux:

   ip route show | grep -i default | awk '{ print $3}'
   

2. Подключитесь к любому серверу Windows с помощью скопированного IP-адреса.

На рисунке ниже показан пример этого, подключаясь к серверу Node.js, работающему под управлением 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-адресом. В настоящее время для включения этого рабочего процесса вам потребуется выполнить те же действия, что и для обычной виртуальной машины. (Мы рассмотрим способы улучшения этого опыта.)

Приведён пример использования команды Netsh interface portproxy Windows для добавления прокси-сервера, который прослушивает ваш порт узла и подключает его к 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. Наконец, значение connectaddress должно быть IP-адресом дистрибутива Linux, установленным через 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 (виртуальной машины)

При использовании 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 (виртуальной машины)

При использовании listenaddress=0.0.0.0 будет осуществляться прослушивание на всех портах IPv4 .

Сетевой режим зеркального отображения

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

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

• Поддержка IPv6
• Подключитесь к серверам Windows из Linux с помощью адреса localhost 127.0.0.1. Адрес локального узла IPv6 ::1 не поддерживается
• Улучшена совместимость работы с виртуальными частными сетями (VPN)
• Поддержка многоадресной рассылки
• Подключение к 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

На компьютерах под управлением Windows 11 22H2 и более поздних версий данная функция включена по умолчанию (которая может находиться [wsl2] в .wslconfig файле) и использует функцию виртуализации для ответа на DNS-запросы из WSL, вместо того чтобы запрашивать их через сетевой пакет. Эта функция предназначена для улучшения совместимости с виртуальными частными сетями (VPN) и другими сложными сетевыми настройками.

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

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

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

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

• Дополнительные сведения о функциях безопасности Windows, которые будут автоматически применяться к WSL, см. в разделе Брандмауэр Защитника Windows с расширенной безопасностью.
• Дополнительные сведения о применении этих правил и параметров как локально, так и с помощью сетевых средств, таких как Intune, см. в настройке брандмауэра Hyper-V.