АВТОМАТИЗАЦИЯ СЕТЕВЫХ КОНФИГУРАЦИЙ В WSL2 ДЛЯ СЕРВЕРНЫХ ПРИЛОЖЕНИЙ

AUTOMATION OF NETWORK CONFIGURATIONS IN WSL2 FOR SERVER APPLICATIONS

Nikita Senyakin

student, Department of Digital Technologies in Transport Process Management, Russian University of Transport (MIIT),

Russia, Moscow

Elena Soymina

scientific advisor, PhD in Engineering, Associate Professor of the Department of Digital Technologies in Transport Process Management, Russian University of Transport (MIIT),

Russia, Moscow

АННОТАЦИЯ

В статье рассматриваются проблемы сетевой конфигурации в среде Windows Subsystem for Linux 2 (WSL2), связанные с динамическими IP-адресами и сложностями проброса портов. Описывается реализация автоматизированного решения на основе проекта wsl-vpnkit, включающая настройку TAP-интерфейса, использование systemd-сервиса и проверку сетевого соединения. Приводится сравнение с альтернативными подходами. Сделаны выводы о надежности и удобстве предложенного метода для развертывания серверных приложений в WSL2.

ABSTRACT

The paper addresses network configuration issues in the Windows Subsystem for Linux 2 (WSL2) environment, focusing on dynamic IP addresses and port forwarding challenges. It describes the implementation of an automated solution based on the wsl-vpnkit project, including TAP interface setup, use of a systemd service, and network connection checks. A comparison with alternative approaches is provided. Conclusions are drawn about the reliability and convenience of the proposed method for deploying server applications in WSL2.

Ключевые слова: WSL2, VPNKit, TAP, systemd, проброс портов, автоматизация, виртуализация, Linux.

Keywords: WSL2, VPNKit, TAP, systemd, port forwarding, automation, virtualization, Linux.

ВВЕДЕНИЕ

Подсистема Windows для Linux (WSL) второй версии предоставила разработчикам удобную среду для запуска Linux-дистрибутивов непосредственно в Windows, используя виртуализацию Hyper-V. Однако несмотря на значительные улучшения в производительности и совместимости, сетевые возможности WSL2 остаются ограниченными. Одной из ключевых проблем является отсутствие стабильного IP-адреса, назначаемого WSL2-инстансу при каждом запуске. Это делает невозможным простую настройку проброса портов или доступ к сервисам, работающим внутри WSL2, из внешней сети.

Существующие решения, такие как ручная настройка портов через `netsh interface portproxy`, неудобны, нестабильны и требуют постоянного обновления конфигурации. В случае серверных приложений, требующих постоянного соединения с определённым IP-адресом (например, для SSH или баз данных), такое поведение WSL2 становится критическим ограничением.

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

1 Обзор WSL2 и его сетевых ограничений

WSL2 основан на полноценной виртуализации с помощью Hyper-V, что означает изоляцию сети от основной Windows-системы. Виртуальная машина получает IP-адрес в локальной подсети Hyper-V, например `172.23.160.X`, который может изменяться при каждом перезапуске WSL. Этот IP не пробрасывается автоматически наружу, и Windows не распознаёт его как часть своей сети.

Таким образом, приложение, запущенное в WSL2 и слушающее на порту 22, недоступно извне без ручного создания правила проброса порта. Классическое решение — использовать `netsh interface portproxy`, например:

```

netsh interface portproxy add v4tov4 listenaddress=192.168.1.104 listenport=22 connectaddress=172.23.160.144 connectport=22

```

Однако это решение требует, чтобы адрес `172.23.160.144` был актуален, а значит необходимо обновлять конфигурацию после каждого запуска.

Кроме того, `portproxy` использует службу `iphlpsvc`, что ограничивает его возможности (например, нельзя пробросить порты на интерфейс TAP). Также он не поддерживает IPv6, и в некоторых случаях соединение сбрасывается на этапе установления соединения SSH (`kex_exchange_identification: read: Connection reset`).

2 Описание архитектуры решения

Для решения указанных проблем был выбран подход с использованием VPNKit и TAP-интерфейса. VPNKit — это компонент, разработанный для среды Docker Desktop, предоставляющий изолированной среде доступ к сети через виртуальный интерфейс.

В рамках проекта VPNKit запускается как демон через обёрточный скрипт, который создаёт TAP-интерфейс с именем `wsltap` и статически назначает ему IP `192.168.127.2`. В качестве шлюза используется IP `192.168.127.1`, а сам хост Windows получает адрес `192.168.127.254`. Эти параметры задаются явно и фиксированы, что устраняет проблему плавающего IP.

Файл `/home/user/wsl-vpnkit/wsl-vpnkit` содержит основной скрипт запуска, где указывается путь к бинарным файлам `wsl-vm` и `wsl-gvproxy.exe`, TAP-имя, адреса DNS и шлюза.

Для автоматизации запуска используется systemd-сервис:

```

[Unit]

Description=wsl-vpnkit

After=network.target

[Service]

ExecStart=/home/user/wsl-vpnkit/wsl-vpnkit

Restart=always

[Install]

WantedBy=default.target

```

Служба устанавливается в `/etc/systemd/system/wsl-vpnkit.service` и активируется командой `sudo systemctl enable wsl-vpnkit`.

3 Практическая реализация и автоматизация

Процесс настройки включает несколько шагов:

1) клонирование репозитория wsl-vpnkit и установка прав доступа на бинарные файлы;

2) изменение переменных окружения в скрипте `wsl-vpnkit` для указания абсолютных путей;

3) запуск и проверка доступности сети (ping, nslookup, wget);

4) создание службы systemd для автоматического запуска при старте WSL;

5) настройка проброса порта через `netsh interface portproxy` на Windows:

```

netsh interface portproxy add v4tov4 listenaddress=192.168.1.104 listenport=22 connectaddress=192.168.127.2 connectport=22

```

6) проверка соединения через `ssh root@192.168.1.104`.

Скрипт также включает автоматические проверки, например, доступность DNS, шлюза, и вывод подробных логов, упрощающих отладку.

4 Эксперименты и результаты

В ходе экспериментов были протестированы следующие аспекты:

- стабильность IP-адреса `192.168.127.2` в интерфейсе `wsltap`;

- возможность подключения по SSH извне без перебоев;

- сравнение времени старта системы и запуска VPNKit;

- проверка ping и nslookup до внешних хостов.

Подключение по SSH оставалось стабильным при всех перезапусках WSL, так как IP не изменяется. `wget` и `ping` до внешних ресурсов (например, `example.com`) выполнялись без ошибок.

Также было проведено сравнение с альтернативными методами:

- `socat` — требует запуска в фоне и нестабилен при сбоях сети;

- `wsl-vpn` — использует обратный прокси, но требует настройки клиента;

- `portproxy` без VPNKit — нестабилен при смене IP.

5 Выводы и направления дальнейших исследований

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

Преимущества:

- статичный IP и устранение необходимости обновлять `portproxy`;

- простота автоматизации через systemd;

- совместимость с IPv4 и частично IPv6.

Возможные направления улучшений:

- создание GUI-утилиты для настройки VPNKit;

- интеграция с WSL2-инсталлятором или `wsl.conf`;

- расширение поддержки IPv6.

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

Список литературы:

1. Microsoft Docs. Windows Subsystem for Linux Documentation. – Режим доступа. – URL: https://docs.microsoft.com/en-us/windows/wsl/ (дата обращения: 01.02.2025)
2. GitHub. wsl-vpnkit project. – Режим доступа. – URL: https://github.com/sakai135/wsl-vpnkit (дата обращения: 17.03.2025)
3. ArchWiki. Systemd service files. – Режим доступа. – URL: https://wiki.archlinux.org/title/Systemd (дата обращения: 20.03.2025)
4. Netsh Command Syntax. Microsoft Docs. – Режим доступа. – URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh (дата обращения: 05.04.2025)
5. RFC 791. Internet Protocol. – Режим доступа. – URL: https://datatracker.ietf.org/doc/html/rfc791 (дата обращения: 06.05.2025)