EN
RUВ этом руководстве подробно описано, как настроить окружение WSL2[^1] с Debian 12[^2] для использования в качестве сервера с постоянным IP-адресом[^4] и доступом из сети Интернет на порты 22 (SSH), 80 (HTTP), 443 (HTTPS) и 3306 (MySQL). Рассматриваются два подхода к сетевой конфигурации – порт-прокси (NAT[^5]) через Windows и бриждинг (мост) через Hyper-V[^9] – с их плюсами и минусами. Также приводятся инструкции по установке необходимых сервисов (SSH[^8]-сервер, веб-сервер, СУБД MySQL/Percona) и настройке удаленного графического доступа (RDP[^7]). После настройки, при перезагрузке Windows WSL-дистрибутив Debian будет автоматически запускаться, а все указанные сервисы станут доступны извне.
Структура статьи: Пошаговые инструкции разделены по ролям пользователей: 1. Обычный пользователь – базовая настройка и запуск сервера. 2. Разработчик – дополнительные настройки для разработки и использования сервера. 3. Администратор – подробно о конфигурации сети, автозапуске и безопасности.
В конце находится Глоссарий, поясняющий все используемые термины (помечены сносками по тексту).
1. Обычный пользователь
1.1. Установка и запуск WSL2 с Debian 12. Если WSL еще не установлен, включите компонент Подсистема Windows для Linux в настройках Windows (через «Windows Features»). Установите дистрибутив Debian 12 из Microsoft Store или вручную. После установки запустите Debian из меню «Пуск» и выполните начальную настройку (создание пользователя и пароля). Убедитесь, что используется версия WSL2 (командой wsl -l -v в PowerShell). Для работы сетевых функций может потребоваться обновление WSL до актуальной версии (выполните wsl —update).
1.2. Настройка статического IP для WSL2. По умолчанию WSL2 работает через внутренний виртуальный коммутатор[^10] Hyper-V и получает динамический адрес в отдельной подсети (WSL2 изолирован от локальной сети LAN). Это затрудняет прямой доступ к WSL извне, т.к. адрес меняется при каждом запуске. Обычным пользователям рекомендуется более простой вариант — оставить внутреннюю сеть по умолчанию и настроить проброс портов через Windows, минуя необходимость ручного управления IP. В этом случае WSL2 будет по-прежнему получать динамический адрес (например, 172.xx.xx.xx), но внешние подключения будут перенаправляться к нему через постоянный адрес Windows (например, 192.168.2.100 в вашей сети). Альтернативный (более сложный) вариант – мост Hyper-V, при котором WSL получает адрес в той же подсети, что и Windows (LAN), и может быть доступен напрямую. Оба подхода описаны в разделе для администратора (см. раздел 3.2 ниже), но здесь мы рассмотрим более простой метод с пробросом портов.
1.3. Проброс портов (порт-прокси) через Windows. В сценарии с NAT Windows будет принимать входящие подключения на указанные порты и перенаправлять их в WSL. Для этого в Windows необходимо настроить правила netsh portproxy. Запустите Windows PowerShell от имени администратора и выполните команды для каждого порта:
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=<Порт_на_Windows> connectaddress=<WSL_IP> connectport=<Порт_в_WSL>
где <WSL_IP> – текущий IP-адрес WSL (его можно узнать командой hostname -I внутри Debian). Например, если WSL сейчас имеет адрес 172.21.47.192 и мы хотим открыть SSH, выполните:
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=22 connectaddress=172.21.47.192 connectport=22
Аналогично добавьте правила для портов 80, 443, 3306 и 33333. Параметр listenaddress=0.0.0.0 указывает, что Windows слушает этот порт на всех сетевых интерфейсах (включая внешний интерфейс с IP 192.168.2.100). После выполнения команд убедитесь, что правила добавлены (команда netsh interface portproxy show all отобразит список).
Важно: так как IP WSL динамический, эти правила могут стать некорректными после перезапуска WSL (при изменении его IP). В разделе для администратора описано, как автоматизировать обновление правил при старте системы (см. раздел 3.2.2). На данном этапе вы можете просто повторять команду netsh interface portproxy set … с новым адресом или воспользоваться автоматизацией, описанной далее.
1.4. Настройка брандмауэра Windows. По умолчанию встроенный брандмауэр[^12] Windows блокирует входящие подключения. Необходимо открыть нужные порты на Windows 10/11: создайте входящие правила для TCP-портов 22, 80, 443, 3306 и 33333 (через интерфейс «Windows Defender Firewall with Advanced Security» или командой New-NetFirewallRule в PowerShell). Укажите для правил профили (Private/Public/Domain) в соответствии с вашей сетью. После этого внешний трафик на эти порты будет допускаться до вашего компьютера и перенаправляться в WSL согласно настройкам portproxy.
1.5. Установка и запуск сервисов в Debian. Теперь перейдите в терминал Debian 12 (WSL) для установки необходимых серверных приложений. Выполняйте команды от имени суперпользователя (добавляя sudo[^21]):
- SSH-сервер: Установите пакет OpenSSH Server: sudo apt update && sudo apt install openssh-server. После установки включите и запустите службу: sudo systemctl enable ssh && sudo systemctl start ssh. Убедитесь, что SSH-служба запущена (systemctl status ssh показывает статус). По умолчанию SSH слушает порт 22 на всех интерфейсах внутри WSL.
- Веб-сервер: Можно выбрать Apache или Nginx. Например, установка Nginx: sudo apt install nginx. Сервис обычно стартует автоматически. Проверьте, что Nginx слушает порты 80 и 443 (HTTPS-порт может быть активен после настройки SSL-сертификата). Если HTTPS нужен, установите сертификат (например, с помощью Let’s Encrypt для реального доменного имени) или временно создайте самоподписанный сертификат для теста. После настройки убедитесь, что сайт открывается локально в WSL (например, curl http://localhost внутри Debian).
- СУБД MySQL (Percona Server): Percona Server for MySQL – это улучшенная сборка MySQL[^18] с дополнительными возможностями. Установим актуальную версию (8.0) из репозиториев Percona. Сначала добавьте репозиторий Percona:
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
sudo dpkg -i percona-release_latest.generic_all.deb
sudo percona-release setup ps80
sudo apt update
Затем установите сервер MySQL: sudo apt install percona-server-server-8.0. В процессе установки появится диалог для задания пароля пользователя root СУБД – укажите надежный пароль. После установки служба MySQL запустится автоматически, и база данных будет слушать порт 3306. Включите удаленный доступ: по умолчанию MySQL слушает только localhost. Откройте файл конфигурации /etc/mysql/percona-server.conf.d/mysqld.cnf и найдите параметр bind-address. Замените значение 127.0.0.1 на 0.0.0.0, чтобы сервер слушал на всех интерфейсах. Затем перезапустите MySQL: sudo systemctl restart mysql. Теперь СУБД будет доступна извне (с учетом проброса порта). Для безопасности создайте отдельного пользователя для удаленного подключения вместо использования root. Также рекомендуется сразу выполнить sudo mysql_secure_installation для базовой защиты (удаление анонимных пользователей, запрет удаленного root-логина и т.д.).
- Графическая среда и RDP-доступ: Если требуется полноценный Linux-рабочий стол внутри WSL, установите легкую графическую среду, например XFCE или LXDE[^16]. Например, XFCE: sudo apt install xfce4 xfce4-goodies. Затем установите сервер RDP xrdp[^17]: sudo apt install xrdp. По умолчанию xrdp прослушивает порт 3389. Настройте xrdp: создайте пользователя для RDP или используйте своего, добавьте его в группу «ssl-cert» (для доступа к сертификату xrdp): sudo adduser <имя> ssl-cert. Можно изменить порт xrdp на 33333, но проще оставить 3389 и настроить проброс – что мы уже сделали (в Windows portproxy для 33333 -> WSL:3389). Запустите и включите xrdp: sudo systemctl enable xrdp && sudo systemctl start xrdp. Убедитесь, что в /etc/xrdp/xrdp.ini указан порт 3389. Теперь вы сможете подключаться к среде XFCE в WSL через любой RDP-клиент, указывая адрес вашего компьютера (WAN[^22]-IP или доменное имя) и порт 33333. После ввода учетных данных откроется сеанс XFCE внутри WSL.
1.6. Автозапуск сервисов и WSL при перезагрузке. Установленные службы (ssh, nginx, mysql, xrdp) уже настроены на автоматический старт при запуске Debian благодаря systemd[^13] (подробнее об активации systemd в WSL см. раздел 3.1.2). Однако сама WSL по умолчанию не запускается вместе с Windows – дистрибутив стартует при первом обращении. Чтобы обеспечить доступность сервисов сразу после перезагрузки Windows, необходимо инициировать запуск WSL и служб на этапе загрузки системы: — Включение systemd в WSL: Отредактируйте файл /etc/wsl.conf в Debian, добавив строчки:
[boot]
systemd=true
Сохраните файл и перезапустите WSL (wsl —shutdown в PowerShell, затем заново откройте Debian). Эта настройка включает поддержку systemd внутри WSL. Убедитесь, что systemd активен: команда systemctl в WSL должна выводить список сервисов без ошибки. На Debian 12 пакет systemd установлен по умолчанию, но проверьте наличие systemd-sysv (если нет – sudo apt install systemd-sysv). Теперь службы, установленные ранее, будут стартовать автоматически при запуске WSL (поскольку мы выполнили enable для них).
- Автозапуск WSL при старте Windows: Откройте Task Scheduler (Планировщик заданий Windows). Создайте новое задание: Triggers – «At system startup» (при запуске системы, с задержкой ~30 секунд для надежности), Action – «Start a program». В поле Program укажите: wsl.exe и аргументами – -d Debian -u root /bin/true. Это задание при загрузке Windows просто запустит невидимый процесс WSL, который инициализирует наш Debian (PID 1 запустит systemd, который, в свою очередь, запустит sshd, nginx, etc.). Установите опцию «Выполнять независимо от входа пользователя» и права администратора. Сохраните задачу. Теперь после каждого перезапуска Windows WSL Debian будет автоматически поднят через ~30 секунд, и все сервисы станут доступными из Интернета (при условии, что настроен проброс портов, см. шаг 1.3).
Примечание: WSL по своей природе может автоматически остановиться, если не остается активных процессов или нагрузки. Наша настройка с systemd и службами обычно предотвращает выгрузку – демоны (особенно sshd) работают в фоне. Тем не менее, если замечаете, что через длительное время бездействия WSL «усыпает», можно добавить дополнительный триггер пробуждения (например, планировщик, выполняющий wsl -d Debian -u root /bin/true каждые N минут) либо настроить параметр vmIdleTimeout в файле .wslconfig Windows (например, vmIdleTimeout=0 для отключения таймаута автозавершения). Эти тонкости рассмотрены в разделе для администратора.
1.7. Проверка доступности из Интернета. Теперь протестируйте все сервисы: — Подключитесь по SSH извне: с другого компьютера или через мобильный интернет выполните ssh <пользователь>@<ваш_WAN_IP> -p 22 (или используйте PuTTY, указав хост – внешний IP/домен и порт 22). Должен открыться запрос пароля SSH. Если соединение не проходит, проверьте корректность проброса порта 22 (в Windows и на роутере MikroTik), а также правила брандмауэра. — Откройте браузером http://<ваш_WAN_IP> (порт 80) и https://<ваш_WAN_IP> (порт 443). Должна отобразиться страница вашего веб-сервера (например, стандартная страница Nginx). Если HTTPS не настроен должным образом, браузер может предупредить об отсутствии сертификата – этим можно заняться позже. — Проверьте RDP: в стандартном клиенте «Подключение к удаленному рабочему столу» (mstsc) в качестве компьютера введите <ваш_WAN_IP>:33333. Должно появиться окно входа xrdp. Введите учетные данные Linux-пользователя – вы должны попасть на рабочий стол XFCE Debian. — Проверьте подключение к MySQL: установите на внешнем клиенте MySQL (например, MySQL Workbench на Windows) соединение к <ваш_WAN_IP>:3306 под созданным SQL-пользователем. Либо прямо из Windows можно попробовать подключиться через консоль: mysql -h 127.0.0.1 -P 3306 -u <user> -p – если порт 3306 проброшен на локальный хост, это соединение попадет в WSL MySQL.
Если все проверки успешны, базовая настройка завершена. Обычный пользователь теперь имеет работающий сервер Debian в WSL2, доступный по нужным сервисам из внешней сети.
2. Разработчик
2.1. Использование WSL2-сервера в процессе разработки. Настроенное окружение позволяет разработчику разрабатывать и тестировать веб-приложения на локальном Linux-сервере, который имитирует боевое окружение, при этом доступен извне для демонстрации или тестирования на реальных устройствах. Рассмотрим несколько практических моментов:
- Доступ к файлам проекта: Вы можете хранить файлы сайта либо внутри файловой системы WSL (например, в каталоге /home/<user>/projects), либо на стороне Windows (например, на диске C) и примонтировать их в WSL. Первый вариант предпочтительнее по скорости, поскольку файловые операции внутри WSL2 выполняются быстрее. В то же время доступ к файлам WSL из Windows возможен через путь \\wsl$\Debian\home\… в Проводнике. Это удобно, например, для редактирования кода в удобном Windows-редакторе (VS Code, Sublime и т.п.), сохраняя изменения прямо в WSL. VS Code, кстати, имеет расширение Remote — WSL, которое позволяет запускать серверную часть редактора внутри WSL и работать с проектом прозрачно. Такой подход устраняет проблему различий окружений: код запускается в WSL с Linux-библиотеками, а вы редактируете его с комфортом на Windows.
- Конфигурирование веб-сервера для разработки: В Debian вы можете настроить виртуальные хосты на Nginx/Apache, включить автоперезагрузку приложений и прочие утилиты. Например, для веб-приложения можно открыть дополнительный порт (скажем, 3000) для dev-сервера Node.js – его тоже можно пробросить через Windows (как делали для 80/443). Разработчику важно помнить, что каждый новый порт нужно либо пробрасывать через netsh (если используете NAT-метод), либо если настроен мост – добавлять правило dst-nat на роутере. В разделе для администратора (см. 3.2.1) описано, как добавить правила portproxy.
- Подключение к базе данных: При разработке вы можете подключаться к MySQL как изнутри WSL (локально через сокет/127.0.0.1), так и с хоста Windows или других машин по сети. Например, если у вас IDE или клиент БД на Windows, используйте хост 127.0.0.1 и порт 3306 – благодаря portproxy это соединение пойдет в WSL. Аналогично, коллеги в вашей сети или CI/CD скрипты могут обращаться к БД по адресу 192.168.2.100:3306 (IP вашего Windows-хоста в LAN) или по внешнему IP (если открыть firewall для интернета, что обычно нежелательно для БД, см. безопасность ниже). Убедитесь, что в MySQL созданы учётные записи с нужными привилегиями и с хостом доступа % (любой) или конкретными IP, иначе MySQL может отвергать подключения даже при правильном пробросе.
- Тестирование внешнего доступа: Одно из преимуществ текущей настройки – возможность протестировать ваше приложение в условиях, близких к реальным: через интернет. Например, вы можете разрабатывать веб-сайт и демонстрировать клиенту или тестировать с мобильного устройства, обращаясь к публичному URL (если настроили DNS на ваш внешний IP) или напрямую по IP. Убедитесь, что Mikrotik направляет входящие запросы на нужные порты. Пример: если у вас дома динамический внешний IP, можно использовать сервис типа DDNS, чтобы присвоить доменное имя, и на Mikrotik настроить dst-nat для портов 80/443. Тогда ваш сайт на WSL будет доступен по этому домену. Это упрощает тестирование интеграций (вебхуки, OAuth редиректы и др.), которые требуют реальный публичный адрес.
- RDP и GUI для разработки: Хотя основная работа разработчика обычно в редакторах/IDE на Windows, бывает полезно запустить Linux GUI-приложение. Мы настроили XFCE и xrdp – теперь вы можете подключиться по RDP (как в шаге 1.7) и получить полноценный рабочий стол Debian. Это может понадобиться для отладки приложений, запуска Linux-версий программ, работы с утилитами, имеющими графический интерфейс (например, Meld для сравнения файлов, терминальные эмуляторы Linux и т.п.). Имейте в виду, что WSLg (если у вас Windows 11) позволяет запускать отдельные графические приложения Linux прямо на рабочем столе Windows без RDP, но такой способ рассчитан на локальное использование. RDP же удобен, когда вы находитесь вне дома и хотите попасть на свою WSL-машину удаленно с интерфейсом (например, через Remote Desktop на планшете). Помните, что производительность графики в WSL ограничена (отсутствует аппаратное ускорение 3D), но для большинства админских задач или легких программ ее достаточно.
2.2. Управление и обновление окружения. В процессе разработки окружение может меняться – новые порты, новые сервисы, обновления ПО: — Установка дополнительных компонентов: Вы можете свободно устанавливать в Debian любые пакеты (например, Git, компиляторы, Docker и пр.). Если вы, например, решили использовать Docker в WSL для тестирования контейнеров, то с включенным systemd это стало возможно (Docker Engine можно установить и запускать как службу). Убедитесь лишь, что ресурсы Windows достаточно велики для новых задач (память, CPU). По умолчанию WSL2 может использовать до 50% RAM и всех CPU, но при необходимости это можно ограничить через файл .wslconfig (например, если вы заметили, что сборка Docker потребляет слишком много памяти, задайте memory=4GB и т.д. – но это для продвинутых случаев).
- Обновление Debian и сервисов: Рекомендуется регулярно обновлять пакеты: sudo apt update && sudo apt upgrade. Это важно для безопасности, особенно учитывая, что система доступна из интернета. Патчи ядра, библиотек OpenSSL, Nginx и др. будут таким образом применяться. В WSL ядро обновляется через Microsoft (wsl —update), а пользовательское пространство через apt. Также следите за обновлениями Windows и WSL – они могут приносить новые функции, важные для разработчиков (например, более быстрая файловая система, поддержка новых сетевых режимов).
- Логи и отладка: Разработчику важно уметь проверять логи сервисов при возникновении проблем. В WSL Debian работают обычные Linux-службы, поэтому логи доступны в /var/log/. Например, /var/log/nginx/error.log для Nginx, syslog для общесистемных сообщений, mysql/error.log (в каталоге БД) для MySQL, auth.log для входов SSH. Используйте sudo journalctl -u <service> для просмотра журналов systemd-сервисов (если systemd включен). Если, к примеру, сервис не слушает нужный порт, проверьте конфигурацию и лог – возможно, произошла ошибка при старте. Также можно использовать утилиту ss -tnlp внутри WSL, чтобы убедиться, что процесс слушает на правильном адресе/порту.
- Работа с MikroTik для тестовых сред: Если у вас несколько разработчиков или несколько тестовых серверов, может возникнуть потребность в различных правилах на роутере. Например, два разработчика хотят открыть каждый свой SSH наружу. Можно на Mikrotik задать разные внешние порты, например 2222 -> Dev1 (WSL), 2223 -> Dev2 (другая машина), либо каждому дать свой внеш. IP (если есть запасные). Как разработчику, в идеале вам не придется лезть в настройки роутера – этим занимается админ. Но иметь представление полезно: правила NAT на MikroTik описаны в разделе 3.3.1. В тестовой среде желательно минимально открывать порты – например, может быть не стоит открывать 3306 в интернет вообще, если достаточно доступа из локальной сети. Вы можете поднимать VPN для доступа к своей среде, вместо прямого открытия – но это уже выходит за рамки данной статьи.
2.3. Безопасность и лучшая практика при разработке. Хотя окружение используется в первую очередь для разработки, оно доступно из вне – а значит, требуется ответственно относиться к безопасности: — Пароли и ключи: Убедитесь, что везде установлены надежные пароли (особенно для SSH и MySQL). Рассмотрите возможность настроить аутентификацию по SSH-ключам[^8] и отключить вход по паролю для SSH вообще. В Mikrotik можно ограничить доступ по IP (например, разрешить SSH к вам только с определенных адресов, если известно откуда будете подключаться). — Firewall (Linux): Debian сам по себе не включает строгий фаервол, но вы можете настроить ufw или iptables для ограничения входящего трафика внутри WSL. Например, если MySQL 3306 вам нужен только для внутренних нужд или доступа из нескольких мест, можно ограничить источник. Однако, поскольку Windows уже выполняет роль брандмауэра и NAT, возможно, достаточно настроить фильтрацию на уровне Mikrotik (что предпочтительнее – см. раздел 3.3.2). — Изоляция сред: Помните, что WSL – не полная замена отдельного сервера. Все сервисы работают под одной Linux-OS, что для разработки удобно, но при тестировании разных версий ПО может быть сложно. Если требуется развернуть что-то несовместимое (другую версию базы, например), можно установить второй дистрибутив WSL (WSL позволяет несколько дистрибутивов параллельно) и настроить для него свои порты. Либо воспользоваться Docker контейнерами внутри WSL. — Мониторинг: Для длительной работы сервера (даже тестового) полезно настроить мониторинг – хотя бы установить htop для наблюдения за нагрузкой, настроить отправку почты или Telegram-оповещений при каких-то событиях (например, использовать скрипт для отправки уведомления, если сервис упал). Разработчику такие меры помогут быстрее заметить проблемы во время тестирования.
В этом разделе мы рассмотрели, как эффективно использовать настроенный WSL-сервер в повседневной разработке. Далее мы перейдем к разделу для администраторов, где те же задачи разобраны более глубоко – это поможет в случае сложных требований или необходимости тонко настроить сеть и систему.
3. Администратор
В этом разделе приведены детальные технические сведения и расширенные инструкции, предназначенные для системных администраторов и опытных пользователей. Мы рассмотрим устройство сети WSL2 и Windows, два способа организации доступа (через NAT/порт-прокси и через мост Hyper-V), настройку роутера MikroTik для проброса портов, а также обсудим автоматизацию запуска и вопросы безопасности.
3.1. Архитектура сети WSL2 и Windows.
WSL2 запускает облегченный виртуализированный Linux на базе Hyper-V. Сетевая схема по умолчанию следующая: — Windows создает виртуальный коммутатор (vSwitch) типа Internal под названием WSL и подключает к нему виртуальную сетевую карту Linux. — Linux (Debian) получает от Windows IP-адрес из специальной подсети (обычно 172.16-31.0.0/20). Вы можете увидеть этот IP внутри WSL командой ip addr (интерфейс eth0). Windows выступает для WSL в роли шлюза (имеет адрес в этой же подсети) и NAT-транслирует исходящий трафик WSL в вашу реальную сеть. — Внешние устройства из LAN не могут напрямую обратиться к WSL, т.к. виртуальный коммутатор изолирован (Internal vSwitch не маршрутизирует в LAN). Именно поэтому без дополнительных действий WSL2 не доступен извне.
Администратору доступны два основных подхода: — A. Использовать NAT и порт-прокси Windows. Оставляем схему по умолчанию (WSL в своей подсети), но на Windows настраиваем пересылку нужных портов. Windows в данном случае слушает эти порты на своем адресе LAN и переадресует трафик внутрь WSL. Этот вариант мы настроили для обычного пользователя. Он не требует сложной конфигурации сети, но добавляет зависимость от динамического IP WSL (что решается скриптом) и потенциально небольшую прослойку в виде TCP-прокси. — B. Включить WSL в локальную сеть (bridge). В этом сценарии виртуальный коммутатор WSL меняется на тип External и привязывается к вашей физической сетевой карте. WSL получает непосредственный доступ к LAN: можно вручную назначить ему адрес из подсети 192.168.2.0/24 или настроить DHCP. В итоге WSL выступает как полноправный узел сети, наравне с Windows. Входящие подключения с роутера Mikrotik можно направлять прямо на IP WSL, минуя Windows (Windows здесь только мостит трафик на уровень Hyper-V). Этот вариант сложнее настроить, требует прав администратора и возможности включить Hyper-V, но избавляет от проблемы динамического IP – вы можете закрепить адрес навсегда и обращаться к WSL как к отдельному серверу.
Далее рассматривается реализация обоих подходов.
3.2. Настройка доступа через Windows (NAT + порт-прокси)
Этот способ хорош тем, что не требует изменения глобальных настроек сети и работает даже на Windows Home (где нет полноценного Hyper-V Manager, но WSL2 все равно функционирует). Мы частично его уже описали, здесь – более формально и с автоматизацией.
3.2.1. Настройка portproxy в Windows. Instrument netsh interface portproxy позволяет Windows переадресовать входящие TCP-соединения с одного IP:порта на другой. В нашем случае слушателем будет любой интерфейс Windows (0.0.0.0) на указанных портах, а целевым – IP-адрес и порт внутри WSL. Пример команды мы приводили ранее. Общий синтаксис:
netsh interface portproxy add v4tov4 ^
listenaddress=0.0.0.0 listenport=<порт_Windows> ^
connectaddress=<IP_WSL> connectport=<порт_WSL>
Для каждого нужного порта создайте правило. Можно выполнять команду несколько раз, подставляя значения: — 22 (SSH) — 80 (HTTP) — 443 (HTTPS) — 3306 (MySQL) — 33333 (RDP внешн.) -> 3389 (внутри WSL xrdp)
Проверьте, что порт не занят самим Windows: например, 3389 уже используется службой RDP Windows (если включено) – мы потому и выбрали внешний порт 33333, чтобы не конфликтовать. Аналогично, 80 или 443 мог быть занят IIS или другими программами – убедитесь, что они свободны.
После добавления правил portproxy уже работает, но есть нюанс: при перезапуске Windows эти правила сохраняются, а вот WSL при каждом запуске может получать новый IP. Если IP изменится, существующие правила будут указывать на неактуальный адрес. Можно вручную обновлять (командой netsh interface portproxy set …), но администратор предпочтёт автоматизацию.
3.2.2. Автоматическое обновление portproxy и запуск служб. Решение – скрипт, выполняющийся при загрузке Windows: 1. Получение IP WSL: После старта WSL его IP можно узнать командой wsl hostname -I из Windows. Например, PowerShell код: $wsl_ip = (wsl hostname -I).Trim(). Как отмечено на SuperUser, «IP-адрес WSL2 не может быть сделан статическим, однако его можно получить командой wsl hostname -I»[1]. 2. Добавление/обновление правил portproxy: Зная $wsl_ip, можно в цикле пройтись по списку портов и обновить правила. Если правила ранее не было – оно добавится, если было – можно либо удалить и добавить, либо воспользоваться netsh interface portproxy set … (как советовали некоторые пользователи). 3. Запуск нужных сервисов внутри WSL: Так как мы включили systemd, это не столь критично – systemd уже запустит sshd, nginx, etc. Но если systemd не используется, пришлось бы запустить ssh вручную. В нашем случае для надёжности можно в скрипте выполнить: wsl -d Debian -u root service ssh start (и аналогично для других, либо сразу service ssh start && service nginx start …). В примере одного из решений сначала запускается ssh: wsl.exe sudo /etc/init.d/ssh start[2]. 4. Автоматизация через Task Scheduler: Оформляем это в .ps1 или .bat файл. Допустим, создаём C:\scripts\wsl_portproxy.ps1 с нужными командами. Далее в PowerShell (от админа) регистрируем задачу (как в примере):
$trigger = New-JobTrigger -AtStartup -RandomDelay 00:00:15
Register-ScheduledJob -Trigger $trigger -FilePath C:\scripts\wsl_portproxy.ps1 -Name WSLPortProxyUpdate
Этот код добавит задачу, которая при старте Windows спустя ~15 секунд запустит наш скрипт[3]. Мы используем ScheduledJob, чтобы задача работала в фоновом режиме без окна. Важно: убедитесь, что политика выполнения PowerShell позволяет запуск скрипт (при необходимости установите Set-ExecutionPolicy RemoteSigned).
- Проверка: Перезагрузите Windows и убедитесь, что после старта правила portproxy указывают на актуальный IP. Можно добавить в скрипт логирование или вывод текущего IP (как в примере на SuperUser, где скрипт выводит WSL Machine IP: … для проверки).
Этот метод гарантирует, что после каждой перезагрузки Windows или WSL, порт-прокси перенастраивается под текущий IP WSL. В сочетании с автозапуском WSL (как настроено в разделе 1.6) это даёт непрерывную работу сервиса. Примечание: В некоторых случаях WSL может перезапустить сеть (например, после wsl —shutdown или выхода из спящего режима Windows). Скрипт, привязанный только к событию старта Windows, не отловит смену IP в такой ситуации. Можно подумать о запуске задачи и при событии Event Triggers (например, мониторинг события перезапуска LxssManager). Однако на практике IP WSL обычно стабилен до следующей перезагрузки Windows.
3.2.3. Плюсы и минусы NAT/порт-прокси метода. — Преимущества: Простота реализации, не требует сторонних инструментов. Подходит на всех редакциях Windows 10/11. WSL изолирован, что может повышать безопасность (Linux не «торчит» в локальной сети, доступен только по тем портам, что вы пробросили). Windows Firewall контролирует доступ извне, можно пользовать все его возможности (фильтрация по IP, профилям). Кроме того, Windows выполняет NAT, что исключает конфликты IP. — Недостатки: Динамический IP WSL требует костылей (скриптов), хотя описанное решение смягчает проблему. Небольшое снижение производительности возможно из-за двойной маршрутизации: пакет из сети приходит на Windows, затем пробрасывается в WSL (накладные расходы минимальны, но есть). Некоторые приложения или протоколы, работающие не только по TCP, сложнее пробросить (например, ICMP (ping) – Windows portproxy не перенаправляет его; UDP тоже возможен, но команда будет другой, и нужно убедиться, что portproxy поддерживает UDP). Ещё один нюанс: с помощью portproxy невозможно пробросить порты <1024 на Windows, если Windows уже их использует. Например, если Windows-система сама должна что-то слушать на 80, возникнет конфликт. В таких случаях NAT-подход может потребовать изменения портов для Windows-сервиса либо отказаться от проброса данного порта. — Безопасность: Нужно помнить, что Windows теперь открыта на эти порты. Обязательно задайте сложные пароли и следите за обновлениями Windows, так как атака идёт как бы на Windows (порт открыт в системе). С другой стороны, трафик по сути сразу переадресуется в Linux, но сетевая служба Windows (portproxy) занимается этим на уровне ядра. Имейте в виду: Windows Firewall не видит внутренний переход – он фильтрует только до Windows. Linux внутри WSL должен сам контролировать, что с ним соединяются. В идеале, ограничьте на уровне Mikrotik источники, если это уместно (см. 3.3.2).
3.3. Настройка доступа через мост (Hyper-V External Switch)
Этот вариант превращает WSL2 в практически обычную виртуальную машину, видимую в локальной сети. Мы предполагаем, что у вас Windows 10/11 Pro (или Windows 11 Home, где Hyper-V частично доступен – начиная с Win11 Home можно включить Hyper-V, хотя на Win10 Home это было невозможно официально).
3.3.1. Переключение виртуального коммутатора WSL в External. 1. Включение Hyper-V: Откройте «Включение или отключение компонентов Windows» и отметьте Hyper-V (включая Hyper-V Platform и Management Tools). Перезагрузите ПК. (Если компоненты Virtual Machine Platform и Windows Hypervisor уже стояли для WSL, всё равно лучше установить полную роль Hyper-V для доступа к менеджеру). 2. Hyper-V Manager: Запустите «Диспетчер Hyper-V» (Hyper-V Manager) с правами администратора. Слева выберите ваш компьютер. Справа нажмите «Virtual Switch Manager». 3. Изменение свича WSL: В списке виртуальных коммутаторов найдите существующий WSL (тип – Internal). Выберите его и переключите тип на External. Ниже выберите сетевой адаптер, через который ваша машина соединяется с сетью (например, Ethernet0 или Wi-Fi). Включите опцию «Allow management operating system to share this network adapter» (обычно по умолчанию, она позволяет Windows-хосту тоже остаться в этой сети). Подтвердите изменения, соглашаясь с предупреждением (на пару секунд сеть может прерваться). 4. Присвоение IP Windows: После применения настроек Windows может потерять IP на этом интерфейсе и затем получить заново (если у вас DHCP в сети). Проверьте ipconfig: у адаптера Ethernet (если проводной) должен остаться тот же IP (192.168.2.100), а у адаптера vEthernet (WSL) вместо старого 172.x появится адрес из вашей подсети (например, 192.168.2.101, если DHCP выдал, или AutoIP 169.254.x.x если нет DHCP). В любом случае, теперь vEthernet (WSL) подключен к физической сети. 5. Настройка IP WSL: Запустите Debian WSL. Заметьте, IP может поменяться. Если у вас есть DHCP-сервер в LAN (обычно роутер Mikrotik выполняет DHCP в подсети 192.168.2.0/24), то WSL может попытаться получить адрес от него. Однако, WSL2-образ не запускает в стандартной конфигурации DHCP-клиент (предполагая фиксированный внутренний сценарий). Поэтому вероятнее всего IP остался старый или стал «нетривиальным». Выполните в Debian:
ip addr flush dev eth0
sudo dhclient eth0
ip addr show eth0
Эта последовательность попробует запросить адрес по DHCP. Если в выводе появился адрес вида 192.168.2.x – отлично, WSL получил адрес от роутера. Можно этот шаг вместо dhclient сделать вручную:
sudo ip addr add 192.168.2.200/24 dev eth0
sudo ip link set eth0 up
sudo ip route add default via 192.168.2.1
(здесь 192.168.2.200 – свободный статический IP, а 192.168.2.1 – адрес шлюза Mikrotik). Как отмечает один источник, после переключения виртуального свича на External, WSL стал доступен в LAN; нужно назначить ему IP из подсети LAN, убедившись, что он уникален. Выберите IP вне DHCP-диапазона, если задаете статически, чтобы избежать конфликта. 6. Сделайте IP WSL постоянным: При мостовом режиме DHCP может выдавать один и тот же адрес (можно настроить reservation по MAC на Mikrotik), либо пропишите статический IP внутри WSL. Статическую конфигурацию можно оформить в /etc/network/interfaces (если используете традиционный ifupdown) или /etc/systemd/network/*.network (если хотите systemd-networkd). Проще всего установить пакет ifupdown и добавить в /etc/network/interfaces:
iface eth0 inet static
address 192.168.2.200/24
gateway 192.168.2.1
dns-nameservers 192.168.2.1 8.8.8.8
После этого при запуске WSL сетевой интерфейс будет сконфигурирован статически. (Не забудьте отключить возможный DHCP-клиент, если он вдруг установлен, чтобы не было конкуренции). 7. Проверка связи: Из WSL попробуйте пропинговать шлюз и внешние адреса:
ping -c 4 192.168.2.1 # проверяем связь с Mikrotik
ping -c 4 8.8.8.8 # проверяем выход в Интернет
Также с другого устройства в LAN попробуйте пинговать IP WSL (192.168.2.200). Если отвечает – значит, WSL успешно интегрировался в локальную сеть.
На этом этапе Debian WSL эквивалентен отдельному хосту в сети 192.168.2.0/24. Все сервисы (22, 80, 443, 3389, 3306) теперь доступны напрямую по этому IP из LAN. Однако из Интернета по-прежнему нужен проброс с роутера. В отличие от NAT-метода, теперь в качестве получателя правил NAT будет не Windows, а сразу адрес WSL.
3.3.2. Настройка проброса портов на MikroTik для WSL. В роутере MikroTik (RouterOS[^3]) создаются правила dst-nat (Destination NAT) для перенаправления входящих соединений с внешнего интерфейса на указанный внутренний IP:порт. Предположим, интерфейс, смотрящий в интернет, называется ether1-WAN (или список интерфейсов WAN). Для каждого порта выполним (можно в терминале MikroTik или через WinBox):
/ip firewall nat add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=22 action=dst-nat to-addresses=192.168.2.200 to-ports=22 comment=»SSH to WSL»
Заменяя dst-port и to-ports на 80,443,3389,3306 соответственно. В действительности to-ports можно опустить, если равен dst-port. Например, правило для веб-сервера:
/ip firewall nat add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=80,443 action=dst-nat to-addresses=192.168.2.200
Так мы одним правилом указали сразу оба порта (80 и 443) на один адрес. MikroTik также позволяет ограничить правило по конкретному внешнему IP (если на роутере несколько), указав dst-address=<your_public_IP>.
В WinBox или WebFig эти же настройки делаются на вкладке IP > Firewall > NAT: — Chain = dstnat — Dst. Port = 80 (например) — In. Interface = WAN (или In. Interface List = WAN) — Action = dst-nat, To Address = 192.168.2.200, To Ports = 80[4].
Каждое правило читается так: «если приходит TCP-пакет на внешний интерфейс (WAN) и порт N, перенаправить его на адрес 192.168.2.200 порт N». После добавления правил сохраните конфигурацию.
Помимо NAT, учтите фильтрацию: стандартная фаерволл-конфигурация MikroTik обычно пропускает входящие подключения только через имеющиеся dst-nat (они маркируются как dstnat и потом правило firewall может их пустить). Проверьте раздел IP > Firewall > Filter Rules. Обычно там есть: — правило, разрешающее установленные соединения (state=established,related) – это пропустит ответы от WSL; — правило, возможно, специально разрешающее new входящие на определенные порты – на базовых конфигах этого нет, обычно просто drop всего, что не established/related.
Чтобы ваши правила заработали, нужно либо: — добавить в Filter Rules разрешение: add chain=forward action=accept connection-nat-state=dstnat in-interface-list=WAN (это означает принимать форвард-трафик, пришедший по dst-nat). В новых версиях RouterOS достаточно того, что connection имеет state=dstnat, и трафик пройдет. — либо отключить/drop, либо настроить правильно адрес списка WAN/LAN.
Проще говоря, если после настроек NAT внешние подключения не доходят (в логах MikroTik видно drop), то надо поправить firewall. Многие обзорные статьи отмечают, что помимо NAT-правила, иногда нужно разрешающее forward-правило[5], если default policy более закрытая.
3.3.3. Проверка внешнего доступа (bridge). Эта проверка аналогична шагу 1.7, но с учетом, что теперь внешний адрес маршрутизатора направляет на IP WSL: — SSH: попробуйте ssh user@<ваш_WAN_IP> (порт 22). Должен быть доступ к WSL (если что – проверьте firewall Mikrotik). — HTTP/HTTPS: откройте внешний адрес – сайт должен работать. — RDP: в клиенте RDP указывайте <WAN_IP>:33333 если вы настроили dst-nat 33333->3389 (тут на Mikrotik вы можете, кстати, сделать также 3389->3389, т.к. Windows RDP нас не волнует, но оставим как есть чтобы соответствовать требованию нестандартного порта). — MySQL: mysql -h <WAN_IP> -P 3306 – проверьте соединение (можно из внешнего VPS или через telnet на порт 3306). Внимание: Открывать СУБД в интернет – риск, убедитесь хотя бы в настройках firewall Mikrotik, что ограничили доступ по IP (например, разрешили 3306 только своему офису). В боевых условиях лучше прокидывать туннель или VPN для доступа к БД.
3.3.4. Плюсы и минусы мостового режима. — Преимущества: WSL имеет постоянный IP в сети – можно настроить Mikrotik один раз, и правила будут работать, пока WSL использует тот же IP. Отпадает необходимость в костылях с netsh и мониторингом IP. Производительность: трафик идет напрямую до WSL минуя лишние уровни трансляции – по сути, MikroTik сразу шлет на Linux IP, Windows всего лишь коммутирует его (накладные расходы минимальны). Видимость: WSL как хост можно использовать и в локальной сети (например, другие устройства LAN могут обращаться к нему по 192.168.2.200 без участия роутера). Это удобно, если, допустим, вы разворачиваете локальный сервис. — Недостатки: Настройка требует правки конфигурации Hyper-V, что не всегда тривиально (и недоступно на Windows Home < 11). При мостовом режиме Windows-хост и WSL-хост разделяют сетевую карту, что теоретически может усложнить сетевое окружение. Например, сеть Wi-Fi обычно не поддерживает несколько IP на одном MAC, поэтому Hyper-V создает виртуальный MAC для WSL. Некоторые Wi-Fi драйверы могут некорректно работать с external vSwitch (хотя в последние годы это надёжно). Кроме того, при отключении/подключении к Wi-Fi может потребоваться перераздача IP. — Безопасность: Теперь WSL открыт внутри LAN, минуя Windows Firewall. Т.е. Windows больше не посредник, весь входящий трафик прилетает прямо в Linux-стек. Поэтому настройте firewall на самом Debian при необходимости (например, ufw). Также Mikrotik теперь NAT-трафик на конкретный IP – удостоверьтесь, что правила фильтрации на роутере разрешают только нужное. Впрочем, если у вас сегмент 192.168.2.0 доверенный (домашняя сеть), тут мало что поменялось: WSL просто стал ещё одним устройством. — Сложность управления: Если вы часто переключаетесь между разными сетями (например, ноутбук, который бывает то в Ethernet-сети, то в Wi-Fi), external vSwitch нужно связывать с активным адаптером. Hyper-V позволяет создать несколько vSwitch (под каждую физику). WSL вроде бы использует всегда WSL свитч – возможно, придётся переключать его, если, скажем, работаете по Wi-Fi. Это не слишком удобно. NAT-метод в этом плане более гибок – он работает независимо от того, как вы подключены к интернету (Wi-Fi или LAN, NAT подстраивается). — Конфликты IP: Следует тщательно следить за IP-адресом WSL – вручную выбранный статический не должен пересекаться с DHCP пулами и другими статическими. Также MAC-адрес виртуального адаптера WSL можно узнать командой ip link – при необходимости привяжите DHCP-резервирование на Mikrotik, чтобы один раз прописать и не беспокоиться.
В итоге, мостовой режим рекомендован, если вам критично иметь постоянный IP и прямое подключение (например, для интеграции в существующую инфраструктуру). Для разового же проброса пары портов зачастую проще остаться на NAT и использовать portproxy.
3.4. Автоматический запуск WSL и служб при старте Windows. (Этот вопрос частично разбирался в 1.6, но для полноты включаем и для админа, с доп. нюансами.)
После выбора сетевого метода, задача администратора – обеспечить автозагрузку сервера. Теперь, когда у нас включен systemd, мы можем полагаться на него: — Убедитесь, что все сервисы включены на автозапуск: systemctl enable ssh nginx mysql xrdp (соответственно для установленных). В Debian ssh означает sshd, mysql – сервис MySQL (или percona-server в нашем случае, мог назваться mysql). — Как отмечалось ранее, systemd в WSL запускается при старте дистрибутива. Но WSL сам не стартует автоматически. Чтобы исправить это, мы настроили задачу планировщика. Администратор может предпочесть другой способ: например, поместить ярлык в «Автозагрузку» пользователя, вызывающий wsl -d Debian -u root /bin/true скрыто. Однако такой вариант сработает только после входа пользователя в систему, а нам нужно при запуске ОС (без входа). Поэтому Task Scheduler с триггером «At startup» – надёжное решение. Дополнительно, можно настроить триггер «On workstation unlock» или «On login», чтобы в случае ручного перезапуска WSL подхватывать. Но как правило, одного запуска на старте достаточно. — Проверка: Перезагрузите Windows, не входя в систему (если задача установлена на уровне системы). Через пару минут попробуйте подключиться по SSH или пингануть сервер. Если ответ есть – всё хорошо. Если нет – войдите в Windows и посмотрите, стартовал ли WSL. Можно открыть PowerShell и выполнить wsl -l -v – если дистрибутив «Running», значит, проблема в доступности (сеть/NAT), а если «Stopped», значит, задача не отработала. Проверяйте условия задач, наличие прав «Run whether user is logged on or not» и т.д. Для отладки можно временно задать задаче запуск wsl -d Debian -u root bash -c «echo started > /mnt/c/temp/wsl_started.txt» – тогда по наличию файла будет понятно, сработала ли она.
Особенность WSL и простоя: Администратору следует знать, что WSL, запущенный в фоне, по умолчанию не завершается, если внутри есть запущенные процессы в интерактивной сессии. Однако с появлением systemd критерии несколько изменились. Как указано в документации, systemd-службы не удерживают WSL в активном состоянии бесконечно – т.е. если нет открытых сессий и foreground-процессов, WSL может выключиться. В 2025 году механизма принудительно держать WSL запущенным конфигурацией еще нет (есть обсуждения, см. GitHub issue). Поэтому для критически важных сценариев (постоянно работающий сервер 24/7) WSL2 пока немного ненадёжен – возможны случаи, когда он «уснет». Практически, если вы настроили SSH и кто-то может по нему коннектиться, sshd сам удерживает WSL активным, т.к. WSL считает его background task. Но были сообщения, что иногда всё равно через ~15 минут простоя WSL выгружается, особенно на Windows 10. Решение: — Либо вручную увеличивать таймаут (в .wslconfig параметр vmIdleTimeout – однако как видно, у кого-то он не сработал[6]), — Либо запустить фиктивный сервис, не позволяющий системе заснуть. Например, некоторыми предлагался запуск tail -f /dev/null или использование screen/tmux с бессрочной задачей. Один из рецептов – запуск в WSL while true; do sleep 60; done в фоне или использование bash -c «nohup sleep infinity» через автозапуск. Также можно, как в одном блоге, использовать dbus-launch true через команду в автозагрузке Windows[7], что создает фоновый процесс. — Третий путь – прибегнуть к полноценной виртуальной машине (Hyper-V VM) либо контейнеру вместо WSL, если нужна стопроцентная гарантия постоянной работы. Но обычно, для малого домашнего сервера, описанных мер хватает, и WSL работает стабильно.
3.5. Безопасность и обслуживание. Здесь администраторский взгляд: — Обновления безопасности: Следите и за Windows, и за Debian. Windows отвечает за «оболочку» (сеть, хост-система), Debian – за сами сервисы. Установите автоматическое обновление Windows (это стандартно). В Debian можно настроить unattended-upgrades для критических патчей. Однако будьте осторожны: автоматический перезапуск WSL (скажем, если Windows обновится ночью) приведет к краткой недоступности сервера. Возможно, это приемлемо для немиссион-критичных задач, но нужно учитывать. — Резервное копирование: WSL позволяет делать экспорт дистрибутива: wsl —export Debian file.tar. Админ может настроить регулярный экспорт, чтобы иметь backup всей системы. Базы данных, конечно, лучше бэкапить отдельным дампом (mysqldump/xbstream), но полный export WSL также полезен (восстановить можно на другой машине через wsl —import). — Логи и мониторинг на уровне Windows: Кроме логов Linux, проверяйте Windows Event Viewer, особенно раздел Windows Logs > System, на предмет ошибок LxssManager или HNS. Например, если Hyper-V сеть даст сбой, там будут записи. MikroTik тоже желательно мониторить – включите логирование drop-пакетов на firewall, чтобы видеть, не стучится ли кто-то настойчиво на ваш сервер (SSH-брутфорс из интернета – частое явление, возможно стоит вынести SSH на нестандартный порт или закрыть на firewall лишние IP). — Протоколирование изменений: Документируйте сделанные изменения (например, какие правила NAT добавлены, какие задачи планировщика). Это поможет при отладке или переносе настроек на другую машину. Хорошей практикой будет хранить PowerShell-скрипты (для portproxy) и MikroTik config (можно экспортировать через /export file=cfg). — Ограничения среды WSL: Помните, что WSL2 хоть и близок к полноценной VM, но всё же работает внутри Windows. Например, при выключении Windows ваша Linux-система гасится мгновенно (как при power off для VM), поэтому настроенные UPS-скрипты или корректный shutdown Linux не выполняются. Если это критично (например, вы боитесь потери незаписанных данных MySQL в буфере), рассмотрите настройку Autosave для MySQL (чтобы чаще скидывал транзакционный лог) или используйте UPS для Windows, чтобы она корректно завершалась. Однако, поскольку WSL2 использует ext4 на VHDX, риски потери минимальны – в худшем случае при загрузке WSL выполнится журналирование ext4. — Использование в Production: Как администратор, вы должны оценить, подходит ли WSL2 для реальной эксплуатации. Microsoft позиционирует WSL2 скорее для разработки. Для боевого сервера все же предпочтительнее либо развернуть полноценный Linux-сервер (физически или виртуально), либо использовать контейнеры. Тем не менее, для небольших проектов или личных сервисов WSL2 вполне справляется, что мы и реализовали.
На этом заканчивается раздел для администратора. Вы получили полный контроль над WSL2-сервером: как на уровне Windows, так и внутри Linux. Ниже приводится глоссарий терминов, использовавшихся в статье, для быстрого справочного сведения.
4. Глоссарий
[^1]: WSL2 (Windows Subsystem for Linux 2) – платформа для запуска GNU/Linux окружения внутри Windows 10/11. WSL2 использует легковесную виртуализацию (Hyper-V) и полноценное ядро Linux для обеспечения высокой совместимости с Linux-приложениями при невысоких накладных расходах. Позволяет запускать терминальные и графические программы Linux на Windows, использовать общий файл системы и т.д.
[^2]: Debian 12 (Bookworm) – двенадцатый стабильный релиз дистрибутива Debian GNU/Linux, выпущен в 2023 году. Известен своей стабильностью и обширными репозиториями. В контексте WSL Debian 12 – это установленный в подсистеме дистрибутив, содержащий пользовательское окружение и пакеты Linux.
[^3]: MikroTik – латвийский производитель сетевого оборудования (маршрутизаторы, точки доступа) и разработчик операционной системы RouterOS. Маршрутизаторы MikroTik широко используются в малом и среднем бизнесе и у продвинутых домашних пользователей из-за гибкости настройки. В статье под MikroTik подразумевается маршрутизатор под управлением RouterOS, осуществляющий подключение локальной сети к интернету.
[^4]: IP-адрес – уникальный сетевой адрес устройства в IP-сети. Формат IPv4 адреса – четыре числа (октета) от 0 до 255, например 192.168.2.100. В локальных сетях обычно используются «серые» (частные) IP из диапазонов 10.x.x.x, 172.16–31.x.x или 192.168.x.x. Постоянный (статический) IP означает, что адрес не меняется при перезагрузке устройства, в отличие от динамического, выдаваемого DHCP.
[^5]: NAT (Network Address Translation) – технология трансляции сетевых адресов. Позволяет нескольким устройствам локальной сети (с частными IP) выходить в интернет через один внешний IP-адрес. Также NAT применяется для проброса портов – маршрутизатор по определенным правилам перенаправляет входящие соединения на внутренние адреса. В контексте WSL2 NAT также используется самим Windows для связи с WSL-виртуалкой: Windows играет роль маршрутизатора, пряча WSL за своим адресом.
[^6]: Проброс портов (Port Forwarding) – настройка, перенаправляющая трафик с определенного порта на одном устройстве на другой порт другого устройства. Чаще всего речь о перенаправлении внешнего порта роутера на порт внутреннего сервера в LAN. Примеры: проброс портов на MikroTik (dst-nat), или порт-прокси в Windows, который слушает порт и пересылает на WSL. Позволяет сделать сервис, запущенный внутри локальной сети или VM, доступным извне.
[^7]: RDP (Remote Desktop Protocol) – проприетарный сетевой протокол Microsoft для удаленного доступа к графическому рабочему столу. Работает по модели клиент-сервер: сервер (служба TermService на Windows или xrdp на Linux) прослушивает TCP-порт (по умолчанию 3389) и при подключении по протоколу RDP предоставляет удаленный интерактивный сеанс. Используется приложением «Подключение к удаленному рабочему столу» и аналогами. В нашем случае RDP позволяет подключиться к графической среде, работающей внутри WSL.
[^8]: SSH (Secure Shell) – сетевой протокол и утилита для защищенного удаленного доступа к командной строке (и не только) Unix-подобных систем. SSH работает по модели клиент-сервер, по умолчанию на TCP порт 22. Соединение шифруется, аутентификация может быть по паролю или с помощью криптографических ключей. Мы используем SSH для администрирования Debian внутри WSL (удобнее, чем Windows-консоль, особенно если подключаемся из внешней сети).
[^9]: Hyper-V – гипервизор (средство виртуализации) от Microsoft, встроенный в современные версии Windows (начиная с Windows 8/10). Позволяет запускать виртуальные машины с разными ОС. WSL2 работает поверх Hyper-V (используется компонент «Virtual Machine Platform»). Для продвинутых настроек (например, внешние vSwitch) требуются компоненты Hyper-V, недоступные на некоторых редакциях Windows. Hyper-V Manager – графическая консоль управления виртуальными коммутаторами, виртуальными машинами, используемая нами для переключения режима сети WSL.
[^10]: Виртуальный коммутатор (Virtual Switch) – программный аналог сетевого коммутатора (switch), созданный гипервизором для соединения виртуальных машин между собой и с хостом. В Hyper-V есть три типа: External (связанный с физическим адаптером, дает VM доступ к внешней сети), Internal (соединяет VMs между собой и с хостом, но не дает выхода наружу) и Private (только между VMs, без доступа к хосту). По умолчанию WSL2 создает Internal vSwitch «WSL», isolating the WSL VM from the physical LAN. Мы переключали его на External, чтобы WSL получил доступ в LAN.
[^11]: Бриджинг/мостовая сеть – режим, когда виртуальная машина подключается к той же сети, что и хост, наравне с ним. В Hyper-V это реализуется через External vSwitch. В результате VM получает IP из той же подсети, что и хост (например, через DHCP), и взаимодействует с другими устройствами напрямую. Термин «мост» также может относиться к функции объединения интерфейсов, но здесь имеется в виду specifically bridging VM network to LAN.
[^12]: Брандмауэр (фаервол) – сетевой экран, фильтрующий сетевой трафик по заданным правилам. Windows имеет встроенный Firewall (в составе системы безопасности), управляемый через интерфейс WF.msc или netsh/PowerShell. MikroTik RouterOS содержит раздел Firewall для фильтрации и NAT. В контексте статьи мы настраивали Firewall Windows, чтобы открыть порты, и упоминали правила firewall Mikrotik, чтобы пропускать dst-nat трафик. Грамотно настроенный фаервол – ключ к безопасности, он может разрешать или блокировать трафик по IP-адресам, портам, состояниям соединений и пр.
[^13]: systemd – современный менеджер служб и система инициализации в Linux. Управляет запуском демонов, монтированием файловых систем, зависимостями сервисов. В классических дистрибутивах Linux systemd запускается как PID 1 при загрузке ОС. В WSL исторически systemd был отключен (работал облегченный init), но с 2022 г. появилась поддержка systemd в WSL2. В нашем случае включение systemd позволило использовать systemctl для управления автозапуском sshd, mysql и пр. и вообще улучшило совместимость (например, xrdp-session, networkd).
[^14]: DNS (Domain Name System) – система доменных имен, используемая для преобразования понятных адресов (например, example.com) в IP-адреса. DNS-серверы могут быть локальными (например, встроенный в роутер) или публичными (8.8.8.8 – Google DNS). В статье DNS упоминался при настройке статического IP (мы прописывали DNS-серверы вручную). В WSL обычно /etc/resolv.conf генерируется автоматически, но при ручной настройке сети нужно указать DNS, иначе Linux не сможет резолвить доменные имена.
[^15]: DHCP (Dynamic Host Configuration Protocol) – протокол автоматической выдачи сетевых настроек (IP-адрес, маска, шлюз, DNS) клиентским устройствам. Обычно в локальной сети роль DHCP-сервера выполняет роутер. Мы затрагивали DHCP дважды: 1) WSL в NAT-режиме получает IP от внутреннего DHCP Windows; 2) при переключении на External, можно позволить WSL запросить адрес у DHCP роутера Mikrotik. Если DHCP не настроен или для статичности мы отключаем его использование, тогда IP задается вручную.
[^16]: GUI (Graphical User Interface) – графический интерфейс пользователя, в отличие от командной строки (CLI). В контексте Linux GUI обычно означает рабочий стол и окна. В WSL дистрибутивы по умолчанию не имеют предустановленной графической среды, но ее можно добавить (например, XFCE, LXDE – легковесные окружения рабочего стола). Мы установили XFCE4 как пример GUI. Учтите, что GUI в WSL2 требует либо использование WSLg (в Windows 11, позволяет запускать приложения в корне Windows), либо запуск отдельного X-сервера/rdp-сервера, как мы сделали с xrdp.
[^17]: xrdp – серверная реализация протокола RDP с открытым исходным кодом для Linux. Позволяет подключаться к сеансам графического рабочего стола Linux через стандартный RDP-клиент. xrdp обычно работает вместе с X.org: при подключении создает X-сессию и перенаправляет ее по RDP. Порт по умолчанию – 3389. Мы использовали xrdp, чтобы реализовать RDP-доступ к WSL, выбрав внешний порт 33333 на роутере/Windows, направленный на xrdp.
[^18]: MySQL – популярная реляционная база данных. Первоначально разработанная компанией MySQL AB, затем приобретена Oracle. MySQL используется для хранения данных веб-сайтов, приложений и пр. В Debian по умолчанию вместо MySQL устанавливается форк MariaDB. Percona Server for MySQL – это производная от MySQL, развиваемая компанией Percona, полностью совместимая, но включающая дополнительные улучшения, утилиты (например, XtraBackup) и оптимизации производительности. Мы установили Percona Server 8.0 вместо стандартной MySQL, чтобы показать более «энтерпрайзный» вариант. Для работы с MySQL используется порт 3306/TCP.
[^19]: Percona Server for MySQL – см. [^18]. Расширенная версия MySQL, ориентированная на повышенную производительность и надежность. Перcona предоставляет также инструменты администрирования (Percona Toolkit) и специальный движок XtraDB (вариант InnoDB). В установке в Debian Percona репозиторий подключается через пакет percona-release, а сам сервер ставится пакетом percona-server-server-8.0. Для конечного пользователя функционирует идентично MySQL, различия под капотом.
[^20]: APT (Advanced Package Tool) – пакетный менеджер в Debian и производных (Ubuntu и др.). Позволяет устанавливать, обновлять, удалять программное обеспечение из репозиториев. Команды apt/apt-get использовались в статье для установки пакетов (apt install) и обновления списка (apt update). APT автоматически обрабатывает зависимости и упрощает управление ПО в Linux.
[^21]: sudo – утилита в Unix-системах, позволяющая запускать команды от имени суперпользователя (root) или другого пользователя, запрашивая пароль текущего пользователя. В Debian по умолчанию можно настроить пользователя в группу sudo, чтобы он мог выполнять привилегированные действия. Практически каждая административная команда у нас сопровождается sudo, так как прямого root-логина в WSL может не быть (или не рекомендуется им постоянно пользоваться).
[^22]: WAN (Wide Area Network) – термин, обозначающий глобальную сеть (например, интернет), либо сегмент сети, подключенный к интернету. В настройках роутеров интерфейс, ведущий в интернет, часто называется WAN. Мы употребляли слово WAN, когда говорили о доступе «из интернета» или о входящем трафике на роутер. Например, in-interface-list=WAN на MikroTik означает правило применяется к входящему трафику на всех интерфейсах, помеченных как внешние.
[^23]: ОС (Операционная система) – базовое программное обеспечение, управляющее аппаратными ресурсами компьютера и предоставляющее сервисы приложениям. В нашем случае фигурируют: Windows 10/11 – ОС хоста; Debian 12 – ОС внутри WSL (гостевая); RouterOS – ОС роутера MikroTik. Взаимодействие между ними возможно благодаря сетевым протоколам и функциям виртуализации.
[^24]: Виртуальная машина (VM) – программная эмуляция компьютера, на котором можно запускать свою операционную систему. Виртуальная машина изолирована от основной системы, имеет свои виртуальные устройства (CPU, память, диск, сетевую карту). WSL2 близок к концепции VM (использует тонкую VM), но интегрирован более прозрачно. Hyper-V позволяет создавать классические VM, которые можно рассматривать как аналоги WSL, но с полным управлением (BIOS/UEFI, собственная конфигурация и т.д.).
[1] [2] [3] windows 10 — Make IP address of WSL2 static — Super User
[4] [5] Port forwarding — RouterOS knowledge base — MikroTik Documentation
[6] [7] How to keep WSL running in the background