Глава 8. Следуем далее с WSL2

systemd полон всякой всячиной. В его сердцевине имеется некий набор инструментов между имеющимся ядром и вашими приложениями в Linux, чтобы упрвиться с беспорядочным наполнением посредине. Наиболее известен systemd своей инициализацией системы, которая стартует и останавливает службы в фоновом режиме Linux. Он заменяет собой устаревшие системы инициализации, такие как Upstart и SysVinit. При запуске традиционного дистрибутива Linux systemd определяет какие службы требуется запускать для ваших потребностей и в каком порядке с тем, чтобы вы попали исполняющиеся рабочий стол или сервер.

systemd обладает большим числом модульных компонентов и не все дистро Linux применяют все доступные компоненты. Одним из моих любимых компонентов является systemd-nspawn, который выступает заменой традиционного chroot и по моей практике лучше обрабатывает кросс- платформенные контейнеры чем некоторые прочие опции.

Многие приложения всё ещё запускаются без systemd, а также имеются дистрибутивы Linux, которые не полагаются на systemd, например, Devuan, который всё ещё пользуется SysVinit или такими заменами как OpenRC.

systemd совместим до некоторой степени с Solaris Service Management Facility или SMF. systemd это относительно новая разработка в мире Linux, ставшая стандартной для Ubuntu в 2015, однако с тех пор он получил широкое распространение и стал общей зависимостью некоторых современных приложений Linux.

Будущее основного развития Linux намерено основываться на systemd, по крайней мере пока не появится его последующая замена.

В настоящее время WSL не поддерживает systemd. WSL обладает своим собственным упрощённым процессом init, который делает возможным взаимодействие переменных среды и монтирует ваши устройства Windows внутри среды WSL в /mnt/c. Он также позволяет совместное использование файлов и некие прочие вспомогательные операции со средой. Если у вас имеются в systemd некие зависимости, вам следует запускать их вручную. Одна из проблем, с которой вы способны столкнуться здесь состоит в том, что systemd не может запускаться как некий первичный процесс Linux, известный как PID 1, хотя это именно то место где многие полагающиеся на systemd процессы ожидают его обнаружить.

Вместо этого вам придётся запускать systemd вручную и далее порождать некую новую среду, в которой systemd и будет работать в качестве PID 1. Это может быть осуществлено парой различных способов, впрочем как и всё в Linux. На момент написания этих строк имеется ряд перечисленных ниже полезных проектов, которые устраивают это для вас:

Чтобы разрешить systemd (Рисунок 8-1) в вашем активном терминале, причём не применяя ни один из предыдущих проектов, мы запустим некий новый процесс пространства имён с systemd, запущенным с PID 1 и затем переключим свой сеанс терминала в этот пространство имён.

Прежде всего установим утилиту daemonize:

> sudo apt -y install daemonize
		

Затем мы воспользуемся daemonize и unshare для установки пространства имён процесса, вызывая systemd для запуска внутри конкретно этого пространства имён:

> sudo daemonize unshare --fork --pid --mount-proc /lib/systemd/systemd &
		

Затем мы получим значение идентификатора процесса полученного процесса systemd извне его пространства имён с тем, чтобы мы могли корректно входить в это пространство имён:

> SYSTEMD_PID="$(ps -eo pid=,args= | awk '$2=="/lib/systemd/systemd" {print $1}')"
		

Наконец, мы перемещаем сеанс своего пользователя при помощи nsenter в пространство имён данного процесса с тем, чтобы мы могли управлять системой и systemd появлялся бы как PID 1:

> sudo /usr/bin/nsenter --all --target "$SYSTEMD_PID" -- su - "$USER"
		

Microsoft производит некое ядро Linux, оптимизированное под WSL 2. Это оптимизированное ядро содержит исправления для своей среды WSL2, включая поддержку устройства и управление памятью. Вы можете применять любое иное ядро стороннего производителя или собрать своё собственное из основного потока, однако они утратят такие особенные исправления WSL2.

Могут встречаться ситуации когда вы желаете воспользоваться функциональной возможностью ядра, которая по умолчанию не включена в установленном в WSL2 ядре в своё собственное ядро или повторно собрать ядро Microsoft со своими собственными необходимыми оптимизациями. Именно последнее я и рекомендую, если только вы не знакомы с обработкой исправлений между различными ядрами и способны примерять любые отличия.

Одним из таких образцов включения в ядре WSL2 функциональных возможностей является ускорение для гостей KVM в WSL. Это требует выгрузки и регулировки настроек необходимого ядра и повторную сборку такого ядра. Это также требует Windows 10 сборки 20175 или выше и некого ЦПУ Intel. Здесь я покажу как это делается. Основная цель данного упражнения состоит в том, чтобы вы теснее познакомились с различными методами настроек ядра, включая изменение необработанного файла конфигурации и применения инструмента меню настроек ядра.

Ядро WSL2 Microsoft можно найти в GitHub.

Давайте воспользуемся git в WSL для клонирования необходимого нам исходного кода ядра WSL2, причём с глубиной 1, “shallow clone” (неглубокое клонирование), потому как у нас для наших целей нет нужды во всей истории фиксаций для этого ядра Linux (Рисунок 8-2):

> git clone --depth 1 https://github.com/microsoft/WSL2-Linux-Kernel
		

Устанавливаем необходимые зависимости для сборки своего ядра при помощи apt (Рисунок 8-3):

> sudo apt -y install build-essential libncurses-dev bison flex libssl-dev libelf-dev
		

Изменим каталоги, проваливаясь в папку своего проекта Git (Рисунок 8-4):

> cd WSL2-Linux-Kernel/
		

Затем мы собираемся начинать в качестве своей отправной точки со своего файла настроек ядра Microsoft , который мы скопируем в корень своего проекта под именем .config (Рисунок 8-5):

> cp Microsoft/config-wsl .config
		

Если вы предпочитаете редактировать свой файл конфигурации ядра вручную, вы можете открыть свой файл настроек в nano, (VS Code) (Рисунок 8-6), или даже в Notepad и выполнить эти ручные изменения:

> code .config
		

Такие исправления вручную это:

KVM_GUEST=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=m
CONFIG_VHOST=y
 	   

Я в какой- то степени представитель “старой школы” и предпочитаю интерфейс традиционного меню терминала для изменения параметров ядра; оно может быть запущено при помощи соответствующей команды make:

> make menuconfig
		

После небольшой компиляции перед вами появится меню настроек ядра Linux (Рисунок 8-7). Воспользуйтесь клавишами Вверх и Вниз для перемещений вверх и вниз по имеющимся вариантам, Пробелом для выбора между вариантами сборки для каждого элемента (либо off и module, когда для этого варианта доступен module), а также Вводом для входа в некий подкаталог, который указывается при помощи символа --->. Для выбора функций снизу применяйте клавиши стрелок Влево и Направо, включая Exit для подъёма на один уровень вверх в этом меню на меню верхнего уровня, где Exit затем выдаст вам приглашение на сохранение перед выходом из этого инструмента настроек. Вы также можете сохранять и загружать различные файлы настроек.

Прежде всего переместитесь в каталог “Processor type and features” (Рисунок 8-8), применяя стрелки Вверх и Вниз и далее клавиши Ввод для входа в этот каталог.

Затем перейдите к каталогу “Linux guest support” и войдите в этот каталог (Рисунок 8-9). Он уже должен быть включённым, но мы намерены разрешить и некоторые дополнительные функциональные возможности гостевой поддержки.

В каталоге гостевой поддержки Linux разрешим “KVM Guest support” при помощи клавиш стрелок для навигации к соответствующему элементу (Рисунок 8-10) и затем нажимая на клавишу пробела для пометки соответствующей функциональной возможности при помощи *, или, как альтернатива, клавишей Y (Рисунок 8-11).

Затем, применяя клавиши стрелок Влево и Направо выберите Exit и дважды нажмите Ввод для прохода на два уровня выше в этом каталоге настроек. Затем открутите вниз до каталога “Virtualization” (Рисунок 8-12).

Воспользуйтесь клавишей Ввод для входа в этот каталог “Virtualization”. Здесь примените клавишу пробела или Y для пометки при помощи * для разрешения “Kernel-based Virtual Machine (KVM) support”. Далее, для своих целей, мы намерены разрешить “KVM for Intel processors support” в виде модуля, который мы можем загружать и выгружать по необходимости. Выделите это и нажмите на Пробел для его пометки с M или клавишу M для его пометки символом M (Рисунок 8-12).

Основное отличие здесь состоит в том, что те элементы, которые помечаются при помощи * будут собираться в само монолитное ядро. Элементы же, помечаемые M, это модули, которые могут загружаться и выгружаться по необходимости. В данном примере мы собираем “KVM for Intel processors support” в качестве модуля с тем, чтобы мы были способны изменять его настройки и быстро применять эту установку выгружая и перегружая данный модуль. Это также вводит вас в эти понятия и работу с модулями, если вы не знакомы с ними. После того как вы настроили установки KVM для своего варианта, вы можете пожелать вернуться к этому упражнению и повторно собрать данное ядро со встроенной такой функциональностью с тем, чтобы вам не приходилось загружать этот модуль всякий раз, когда вы желаете работать с ним, либо, как альтернатива, добавить название этого модуля ядра в командную строку ядра в .wslconfig.

После включения “Kernel-based Virtual Machine (KVM) support” во встраиваемую сборку и “KVM for Intel processors support” в качестве модуля, дважды выберите Exit и вы получите приглашение на сохранение своей новой конфигурации (Рисунок 8-14). Выберите Yes.

Далее мы соберём своё ядро. Мы применим команду make. Вы можете впечатляющим образом ускорять время сборки устанавливая флаг -j со следующим за ним числом ядер, имеющихся у вашего устройства (или того, что вы определили в .wslconfig). В данном случае у нас имеется 8 ядер, а потому мы запускаем (Рисунок 8-15)

> make -j 8
		

Откиньтесь на спинку кресла и наслаждайтесь чашкой чая пока собирается ваше ядро Linux (Рисунок 8-16).

Если сборка успешна, вы получите информацию об этом (Рисунок 8-17):

Kernel: arch/x86/boot/bzImage is ready
		

было собрано наше монолитное ядро, причём оно находится в подкаталоге нашего текущего каталога arch/x86/boot/bzImage.

Но мы ещё не всё сделали. Теперь мы должны собрать и установить те функциональные возможности, которые мы пометили флагом как модули. Они будут установлены в файловой системе нашего дистро в /lib/modules потому что они не собраны в самом ядре. Выполните команду make как указано ниже для выполнения сборки необходимых модулей и установите их в надлежащих каталогах (Рисунок 8-18):

> sudo make modules_install
		

Теперь, обладая установленными в /lib/modules своими модулями, мы вернёмся к своему файлу монолитного ядра arch/x86/boot/bzImage, нам требуется переместить его в свою файловую систему Windows чтобы сделать его доступным для WSL2. Я рекомендую ваш домашний каталог своего пользователя Windows. Мы можем сделать это при помощи приводимой ниже команды, который скопирует собранное нами ядра туда (Рисунок 8-19). wslvar, часть wslvar выполнит выборку переменной среды %USERPROFILE% из Windows, которую мы затем преобразуем в формат Linux при помощи wslpath:

> cp arch/x86/boot/bzImage $(wslpath $(wslvar USERPROFILE))
		

Затем нам требуется настроить WSL2 на применение своего нового индивидуального ядра. Мы сделаем это при помощи .wslconfig в домашнем каталоге своего пользователя Windows. Откройте .wslconfig следующим образом (Рисунок 8-20):

> nano $(wslpath $(wslvar USERPROFILE))/.wslconfig
		

Если такой файл ещё не существует, nano создаст этот файл для вас. Скопируйте в .wslconfig следующее, выполните регулировки имени своего пользователя в своём пути или весь путь если вы помещаете своё ядро куда- то вне домашнего каталога вашего пользователя Windows:

[wsl2]
kernel=C:\\Users\\Hayden\\bzImage
nestedVirtualization=true
		

Значение пути к нашему индивидуальному ядру Linux должно быть абсолютным, причём здесь не допускаются переменные, а обратные слэши требуют удвоенного обратного слэша. Начиная со сборки 20175 Windows 10, вложенная виртуализация включена по умолчанию, поэтому если вы располагаете более поздней сборкой, это можно опустить. Я всё ещё оставляю ей для полноты счастья.

Затем мы можем установить параметры для своего модуля “KVM for Intel processors support” с названием kvm-intel. Откройте /etc/modprobe.d/kvm-nested.conf следующим образом (Рисунок 8-21):

> sudo nano /etc/modprobe.d/kvm-nested.conf
		

Скопируйте в /etc/modprobe.d/kvm-nested.conf следующее, включая вложенную виртуализацию и расширенные параметры для оптимизации значения скорости вложенных виртуальных машин:

options kvm-intel nested=1
options kvm-intel enable_shadow_vmcs=1
options kvm-intel enable_apicv=1
options kvm-intel ept=1
		

Сохраните изменения в /etc/modprobe.d/kvm-nested.conf и выполните выход.

Затем мы намерены перезагрузить свою среду WSL с нашим новым ядром. Откройте новую закладку PowerShell и остановите WSL таким манером (Рисунок 8-22):

> wsl.exe --shutdown
		

Если вы вернётесь в свою закладку Ubuntu вы должны обнаружить свой процесс как завершивший работу (Рисунок 8-23):

Закройте эту закладку и повторно откройте новую вкладку Терминала Windows для нашего дистро. Это действенно “перезагрузит” нашу среду WSL с загруженным новым ядром.

После “запуска”, вы можете удостовериться что вы работаете с новым ядром исполнив uname и проверив дату и время, которые должны отразить текущие дату и время за вычетом нескольких минут, которые прошли с момента сборки вашего ядра (Рисунок 8-24):

> uname -ar
		

Затем установите инструмент с названием kvm-ok для подтверждения доступности собранной нами в своём ядре вложенной функциональности KVM следующим образом:

> sudo apt -y install cpu-checker
		

Далее выполните kvm-ok следующим образом (Рисунок 8-25):

> kvm-ok
		

Это выдаст отчёт о том, что поддержка KVM не доступна, а также что /dev/kvm не существует. Нам требуется ещё один шаг, загрузить функциональную возможность “KVM for Intel processors support”, которую мы собрали, также носящего название kvm_intel, что мы делаем так (Рисунок 8-26):

> sudo modprobe kvm_intel
		

Теперь повторно выполните kvm-ok (Рисунок 8-27):

> kvm-ok
		

Когда вы получили сообщение “KVM acceleration can be used”, это значит что вы успешно загрузили соответствующий модуль ядра и теперь KVM работает.

Затем мы можем удостовериться в поддержке вложенной виртуализации KVM проверив следующим образом один из параметров, производимый напрямую из нашего модуля kvm_intel (Рисунок 8-28):

> cat /sys/module/kvm_intel/parameters/nested
		

Заключительный шаг настройки KVM под применение состоит в превращении /dev/kvm в доступный через надлежащую установку полномочий для нашего пользователя, что мы устанавливаем так (Рисунок 8-29):

> sudo chmod 666 /dev/kvm
		

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

По мере ваших экспериментов с запуском различных гостевых операционных систем вам может потребоваться изменять установки в /etc/modprobe.d/kvm-nested.conf.

Способ для выполнения этого состоит в выгрузке kvm_intel при помощи

> sudo modprobe -r kvm_intel
		

Затем выполните надлежащие изменения в /etc/modprobe.d/kvm-nested.conf и в конце концов перегрузите свой модуль kvm_intel как и ранее:

> sudo modprobe kvm_intel
		

Как уже обсуждалось ранее, если вы твёрдо уверены в настройке kvm-nested.conf вы можете затем выбрать повторную сборку своего ядра со встроенным kvm_intel вместо модуля. Это обходит потребность загрузки данного модуля вручную при каждом запуске WSL. Вы также можете добавить sudo modprobe kvm_intel в качестве команды [boot] в Windows 10 сборки 21286+.

Мы уже изучили как собирать некое персональное ядро, загружать модули, применять индивидуальные настройки модуля ядра и устанавливать персональное ядро в WSL2; что мы можем делать с этим? Обладая поддержкой вложенного KVM мы способны применять такие инструменты как minikube, которые при запуске контейнеров Kubernetes зависят от KVM. Мы также можем запускать целиком прочие операционные системы напрямую при помощи QEMU, причём не только гостевые Linux, но также и macOS, Arca Noae, OpenIndiana или Haiku.

Давайте пройдёмся по образцу с Kubuntu, разновидностью KDE Ubuntu. Прежде всего установите qemu-kvm, набор инструментов для запуска гостевых операционных систем, а также aria2, инструмент для выгрузки больших файлов, которые мы намерены применять для выгрузки под запуск некого ISO (Рисунок 8-30):

> sudo apt -y install qemu-kvm aria2
		

QEMU отобразит через X некое окно, поэтому вам потребуется обладать настроенным сторонним X сервером, как это было описано в Главе 7, Персонализация WSL или иметь официальную поддержку прикладных приложений с графическим интерфейсом в WSL когда она будет запущена. В качестве быстрого напоминания, вы можете указать свой экземпляр WSL в своём запущенном в Windows X сервере при помощи

> export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2;}'):0.0
		

Затем давайте вытащим некий загружаемый ISO (образ CD диска) гостевой операционной системы. ISO как правило предполагают большой размер, именно поэтому я рекомендую применять aria2 с многопоточной выгрузкой вместо базовых wget или curl. Выгрузите торрент файл установки ISO Kubuntu при помощи aria2 следующим образом (Рисунок 8-31):

> aria2c -x 10 --seed-time=0 http://cdimage.ubuntu.com/kubuntu/releases/20.04/release/kubuntu-20.04.2-desktop-amd64.iso.torrent
		

Затем нам потребуется создать виртуальный жёсткий диск для установки Kubuntu в QEMU в отличие от VHDX, в котором хранится ваша среда WSL2. Для создания виртуального жёсткого диска под Kubuntu, запустите qemu-img create, как показано ниже, создавая 20ГБ диск в формате qcow2, естественном формате виртуального диска для QEMU (Рисунок 8-32):

> qemu-img create -f qcow2 kubuntu.qcow2 20G
		

Профессиональный совет: qemu-img способен преобразовывать образы между QCOW применяемого QEMU, VHDX используемого Hyper-V, а также VMDK употребляемого VirtualBox.

Затем мы запустим Kubuntu (Рисунок 8-33). Выполните следующее:

Исполните следующее:

qemu-system-x86_64 \
      -drive file=kubuntu.qcow2,format=qcow2 \
      -drive file=kubuntu-20.04.2-desktop-amd64.iso,media=cdrom,readonly \
      -net nic -net user \
      -m 5172 \
      -vga qxl \
      --enable-kvm \
      -smp 4 \
      -cpu kvm64,+vmx,+vme,+msr,+x2apic,+hypervisor
		

В предположении что всё предоставленное закончилось успешно, вы теперь должны наблюдать окно с установщиком Kubuntu. Теперь вы можете испытать образ live или выполнить установку на созданный нами виртуальный жёсткий диск. Вы можете сохранить эту команду QEMU в неком сценарии оболочки (Рисунок 8-34), например:

> nano start_kubuntu.sh
		

Скопируйте такое:

#!/bin/bash
qemu-system-x86_64 \
      -drive file=kubuntu.qcow2,format=qcow2 \
      -net nic -net user \
      -m 5172 \
      -vga qxl \
      --enable-kvm \
      -smp 4 \
      -cpu kvm64,+vmx,+vme,+msr,+x2apic,+hypervisor
		

Выйдите, сохранитесь и не забудьте превратить его в исполняемый:

> sudo chmod +x start_kubuntu.sh
		

После того как вы осуществили установку на свой виртуальный жёсткий диск, вы можете опустить ссылку на свой ISO и удалить его, если пожелаете. Вы также можете отрегулировать требования для оперативной памяти и ядер под оптимизацию производительности. Такой подход можно приспосабливать для запуска прочих операционных систем с их установочных ISO.

Сетевая среда WSL1 в целом была относительно базовой. По той причине что WSL1 была уровнем трансляции системных вызовов, такая среда WSL совместно использовала тот же самый сетевой стек что и среда Windows. Иными словами, localhost был локальным хостом.

В WSL2 сетевая среда слегка усложняется. Сетевая среда самой WSL2 обладает собственным IP адресом в подсети NAT DHCP.

Это может приводить к некоторым усложнениям. Одно такое усложнение связано с X, разрешённым в нашей предыдущей главе настройкой X в WSL2. Второе усложнение состоит в доступе к запущенным в WSL2 службам извне вашего устройства. Это также требует открытие порта межсетевого экрана (Брандмауэра) Windows и последующей передачи этого порта в IP среды самой WSL2.

В этом примере мы установим веб сервер apache и затем сделаем возможным доступ к нему из нашей локальной сети.

Прежде всего установим apache (Рисунок 8-35):

> sudo apt -y install apache2
		

После установки мы теперь запускаем веб службу при помощи команды service таким образом (Рисунок 8-36):

> sudo service apache2 start
		

Теперь мы можем воспользоваться wslview, частью wslutilities, поставляемых в пакете в некоторых дистро WSL и доступных для прочих, чтобы открыть страницу запуска по умолчанию для Apache, запущенного в локальном хосте (Рисунок 8-37):

> wslview http://localhost
		

Отображаемая по умолчанию страница запуска для Apache должна быть видна на локальном хосте (Рисунок 8-38), однако она доступна только в локальном хосте. Как нам сделать её доступной для прочих устройств в нашей локальной сети (LAN)?

Прежде всего мы откроем PowerShell и выполним выборку значения IP адреса подключения Ethernet или Wi-Fi всоего устройства Windwos. Этот IP виден и доступен для прочих устройств в нашей локальной сети (Рисунок 8-39):

Далее мы выявляем виртуальный IP адрес, который выделен нашей среде WSL при помощи ip a, в частности, для нашего устройства eth0. В отличии от IP адреса устройства Windows, IP адрес нашей WSL не доступен для прочих устройств в нашей LAN. Нам требуется настроить передачу чтобы превратить запущенную в WSL службу в доступную для прочих устройств в своей локальной сети через IP адрес Windows. Затем нам следует открыть надлежащие порты в межсетевом экране Windows (Рисунок 8-40):

> ip a
		

Как альтрнатива, для определения IP адреса своей среды WSL вы можете применить следующее (Рисунок 8-41):

> ip addr show eth0 | awk -F'[ /]+' '$2=="inet" {print $3}'
		

Если вы попробуете получить доступ к Apache с другого устройства из своей локальной сети, либо через такой IP адрес из этого пункта, такое подключение завершится по тайм- ауту (Рисунок 8-42). Это соединение не передаётся из Windows в нашу среду WSL и, к тому же, оно блокируется межсетевым экраном Windows.

В качестве Администратора в Windows откройте PowerShell и мы создадим, как это показано ниже, посредника (прокси) передачи порта, который свяжет наш IP адрес Windows с IP адресом нашей среды WSL по порту 80, тому порту, который используется Apache (Рисунок 8-43):

PS C:> netsh interface portproxy add v4tov4 listenaddress=192.168.4.122 listenport=80 connectaddress=172.28.202.134 connectport=80
		

Пока мы всё ещё пребываем в PowerShell в качестве Администратора, мы откроем порт в межсетевом экране (Брандмауэре) Windows чтобы разрешить входящие подключения по порту 80 таким образом (Рисунок 8-44):

PS C:> netsh advfirewall firewall add rule name="Open Port 80 for WSL2" dir=in action=allow protocol=TCP localport=80
		

Как альтернатива, мы можем создать некое правило Брандмауэра Windows, допускающее передачу входного обмена в виртуальный адаптер Ethernet для WSL, однако здесь следует принять во внимание, чо это полностью открывает вашу среду WSL для все й сетевой среды, причём без какой бы то ни было защиты со стороны межсетевого экрана Windows. Это делается так (Рисунок 8-45):

PS C:> New-NetFirewallRule -DisplayName "WSL" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow -EdgeTraversalPolicy Allow
		

Однако раз мы имеем передачу своего порта и открытие порта в своём межсетевом экране, наша служба Apache теперь превращается в доступную через IP адрес Windows для прочих устройств в нашей локальной сети (Рисунок 8-46).

Одно важное пояснение состоит в том, что значение IP адреса для вашей среды WSL изменяется всякий раз при запуске, поэтому при перезапуске вам потребуется всякий раз перенастраивать передаваемый порт для передачи надлежащего порта. Вы можете автоматизировать это при помощи команд PowerShell или bash в своём файле .bashrc или при помощи параметра [boot] command= для сборки 21286 или выше Windows 10.

Например, приводимый ниже сценарий может вызываться из варианта [boot] command= в Windows 10 сборки 21286 или выше, или в в вашем файле .bashrc, для настройки передачи порта из вашей физической сетевой среды в ваш экземпляр WSL. Вы можете выявить индекс своего адаптера сетевого интерфейса выполнив в PowerShell Get-NetIPAddress -AddressFamily IPv4 (Рисунок 8-47).

#!/bin/bash
# Configuration
INTERFACE_IDX=9 # Your Windows network device's InterfaceIndex from Get-NetIPAddress in PowerShell
PORT=80
# The script
IPADDRESS="$(ip addr show eth0 | awk -F'[ /]+' '$2=="inet" {print $3}')"
powershell.exe -Command "
\$WINIPADDR=Get-NetIPAddress -AddressFamily ipv4 -InterfaceIndex $INTERFACE_IDX | Select-Object -ExpandProperty IPAddress
Start-Process -Verb RunAs -FilePath netsh.exe -ArgumentList @('interface', 'portproxy', 'add', 'v4tov4', \"listenaddress=\$WINIPADDR\", 'listenport=$PORT', 'connectaddress=$IPADDRESS', 'connectport=$PORT')"