Туннелирование на Windows — PowerShell, WSL, fxTunnel

Зачем Windows-разработчикам нужны туннели

Если вы пишете .NET API в Visual Studio, гоняете Node.js в WSL2 или поднимаете контейнеры в Docker Desktop, рано или поздно локальный сервис нужно показать миру: протестировать вебхуки от Stripe или GitHub, продемонстрировать проект удалённому клиенту, отладить OAuth-коллбэк, подключить мобильное устройство к локальному бэкенду.

Сложность на Windows в том, что туннелирование затрагивает несколько слоёв. Ваш сервис может работать нативно в Windows, внутри дистрибутива WSL2 или в Docker-контейнере. У каждого окружения своя модель сетевого взаимодействия, а Windows Firewall добавляет ещё один уровень. Это руководство охватывает все сценарии: нативная установка через PowerShell, интеграция с WSL2, Docker Desktop, настройка файрвола и решение типичных Windows-проблем.

Общее введение в туннелирование — в статье «Что такое туннелирование».

Установка fxTunnel на Windows (нативная)

fxTunnel работает нативно на Windows как самостоятельный .exe-файл. WSL и Docker не требуются. Установка через PowerShell занимает меньше минуты.

Способ 1: однострочная команда в PowerShell

Откройте PowerShell (обычный или от администратора) и выполните:

# Скачать и установить fxTunnel для Windows
Invoke-WebRequest -Uri "https://fxtun.dev/install.ps1" -UseBasicParsing | Invoke-Expression

Проверьте установку:

fxtunnel --version

Способ 2: Go Install

Если у вас установлен Go:

go install github.com/mephistofox/fxtun.dev/cmd/fxtunnel@latest

Убедитесь, что $env:GOPATH\bin (обычно C:\Users\<вы>\go\bin) добавлен в PATH.

Способ 3: ручная загрузка

Скачайте бинарник для Windows со страницы релизов на GitHub и поместите его в директорию из PATH:

# Скачать бинарник
Invoke-WebRequest -Uri "https://github.com/mephistofox/fxtun.dev/releases/latest/download/fxtunnel-windows-amd64.exe" -OutFile "$env:USERPROFILE\bin\fxtunnel.exe"

# Добавить в PATH для текущей сессии (или постоянно через свойства системы)
$env:PATH += ";$env:USERPROFILE\bin"

# Проверить
fxtunnel --version

Первый туннель на Windows

Запустите локальный веб-сервер (любой фреймворк, любой порт) и откройте туннель:

# Пример: Node.js-сервер на порту 3000
fxtunnel http 3000

Вывод:

fxTunnel v1.x — tunnel is active
Public URL:  https://win-demo.fxtun.dev
Forwarding:  https://win-demo.fxtun.dev -> http://localhost:3000

Press Ctrl+C to stop

Готово. Публичный URL активен, имеет валидный TLS-сертификат и перенаправляет запросы на ваш локальный сервер. Как fxTunnel автоматически обеспечивает TLS, описано в статье «HTTPS на localhost».

Туннелирование из WSL2

WSL2 (Windows Subsystem for Linux 2) запускает настоящее ядро Linux внутри легковесной виртуальной машины. Многие Windows-разработчики используют WSL2 как основное окружение для Node.js, Python, Ruby, Go и других Linux-стеков. Сетевая модель WSL2 имеет особенности, которые нужно учитывать.

Как устроена сеть WSL2

WSL2 создаёт виртуальный сетевой адаптер с собственным IP-адресом. Сервисы внутри WSL2 привязаны к сети виртуальной машины, а не к хосту Windows напрямую. В Windows 10 и ранних сборках Windows 11 использовалась NAT-модель, при которой проброс localhost из Windows в WSL2 работал ненадёжно. В Windows 11 (22H2+) появился режим mirrored networking, который разделяет сетевой стек хоста с WSL2 и обеспечивает корректную работу localhost.

Что это значит для туннелирования:

• Режим mirrored (Windows 11 22H2+): сервисы в WSL2 доступны на localhost из Windows. Можно запускать fxTunnel как на Windows, так и внутри WSL2 — оба варианта работают.
• Режим NAT (по умолчанию в Windows 10): сервисы в WSL2 привязаны к отдельному IP. Проще запустить fxTunnel внутри WSL2. Если запускать fxTunnel на Windows, нужен IP-адрес WSL2.

Вариант A: установка fxTunnel внутри WSL2 (рекомендуется)

Самый простой подход. Установите fxTunnel в дистрибутив WSL2 и запустите его там — никаких проблем с кросс-сетевым взаимодействием.

# Внутри терминала WSL2 (Ubuntu, Debian и т.д.)
curl -fsSL https://fxtun.dev/install.sh | bash

# Запуск туннеля к серверу внутри WSL2
fxtunnel http 8080

Туннель подключается к сервису напрямую в рамках одного Linux-окружения. Никаких поисков IP, правил файрвола и неожиданностей.

Вариант B: fxTunnel на Windows, туннель к WSL2

Если вы предпочитаете запускать fxTunnel нативно на Windows, а сервис WSL2 недоступен на localhost:

# Шаг 1: узнать IP-адрес WSL2
wsl hostname -I
# Пример вывода: 172.23.48.1

# Шаг 2: запустить fxTunnel на Windows с указанием IP WSL2
fxtunnel http 172.23.48.1:8080

Включение mirrored networking (Windows 11)

Если вы на Windows 11 и хотите максимально простой опыт, включите mirrored networking. Создайте или отредактируйте файл %USERPROFILE%\.wslconfig:

# Создать .wslconfig с mirrored networking
@"
[wsl2]
networkingMode=mirrored
"@ | Out-File -FilePath "$env:USERPROFILE\.wslconfig" -Encoding UTF8

Затем перезапустите WSL:

wsl --shutdown
wsl

В режиме mirrored сервисы внутри WSL2 напрямую доступны на localhost из Windows, и fxTunnel можно запускать с любой стороны.

Docker Desktop на Windows

Docker Desktop для Windows запускает контейнеры внутри бэкенда WSL2 (или Hyper-V в старых конфигурациях). Порты контейнеров пробрасываются на localhost хоста Windows, поэтому туннелирование работает точно так же, как для нативного Windows-сервиса.

Туннелирование Docker-контейнера

# Запуск контейнера с пробросом порта
docker run -d -p 8080:80 --name my-app nginx

# Открытие туннеля к проброшенному порту
fxtunnel http 8080

Контейнер теперь доступен из интернета. Другие Docker-сценарии, включая docker-compose, разобраны в статье «Docker + туннель: доступ к контейнерам из интернета».

Docker Compose с fxTunnel

version: "3.8"

services:
  web:
    image: nginx
    ports:
      - "8080:80"

  tunnel:
    image: ghcr.io/mephistofox/fxtunnel:latest
    command: ["http", "web:80"]
    depends_on:
      - web

docker compose up

Контейнер-туннель обращается к контейнеру web по имени сервиса через внутреннюю DNS Docker. Публичный URL появится в логах.

Настройка Windows Firewall

Windows Firewall — самый частый источник проблем с туннелированием на Windows. fxTunnel создаёт исходящее TLS-соединение на порту 443, которое разрешено по умолчанию. Однако корпоративные окружения, сторонние антивирусы и пользовательские групповые политики могут его блокировать.

Проверка соединения

# Проверить исходящее подключение к серверу fxTunnel
Test-NetConnection -ComputerName fxtun.dev -Port 443

Если TcpTestSucceeded показывает True, соединение не блокируется. Если False — нужно добавить исключение в файрвол.

Добавление исключения

# Запустите PowerShell от администратора
New-NetFirewallRule -DisplayName "fxTunnel" `
  -Direction Outbound `
  -Program "$env:USERPROFILE\bin\fxtunnel.exe" `
  -Action Allow `
  -Protocol TCP `
  -RemotePort 443

Укажите правильный путь к fxtunnel.exe в параметре -Program.

Windows Defender и сторонние антивирусы

Некоторые антивирусы помечают неизвестные бинарники, совершающие исходящие подключения. Если fxTunnel блокируется или помещается в карантин:

1. Добавьте fxtunnel.exe в список исключений антивируса.
2. Для Windows Defender добавьте исключение через PowerShell:

# Добавить исключение для бинарника fxTunnel
Add-MpPreference -ExclusionPath "$env:USERPROFILE\bin\fxtunnel.exe"

Туннелирование разных протоколов на Windows

fxTunnel поддерживает HTTP, TCP и UDP на Windows с теми же командами, что и на Linux и macOS. Вот типичные сценарии Windows-разработки.

HTTP: ASP.NET / .NET API

# Ваше ASP.NET Core приложение работает на порту 5000
dotnet run --urls "http://localhost:5000"

# В другом терминале
fxtunnel http 5000

TCP: SQL Server, PostgreSQL

# Туннель к локальному экземпляру SQL Server (порт по умолчанию 1433)
fxtunnel tcp 1433

# Туннель к PostgreSQL
fxtunnel tcp 5432

UDP: игровые серверы, VoIP

# Туннель к игровому серверу
fxtunnel udp 27015

fxTunnel поддерживает все три протокола на бесплатном тарифе, включая UDP, которого нет у большинства аналогов. Разница между протоколами разобрана в статье «TCP и UDP туннелирование».

Решение типичных Windows-проблем

Что-то не работает? Большинство проблем с туннелированием на Windows делятся на три категории: блокировка файрволом и антивирусом, особенности сети WSL2 и конфликты портов. В таблице ниже – самые распространённые ситуации.

Диагностика конфликтов портов

# Найти, что использует порт 8080
netstat -ano | findstr :8080

# Пример вывода:
#   TCP    0.0.0.0:8080    0.0.0.0:0    LISTENING    12345

# Завершить процесс
Stop-Process -Id 12345

Проверка связности с WSL2

# Внутри WSL2: убедитесь, что сервис работает
curl http://localhost:8080

# Из PowerShell Windows: проверьте доступность порта WSL2
wsl curl http://localhost:8080

Проверка зарезервированных портов Hyper-V

Docker Desktop и Hyper-V иногда резервируют диапазоны портов, конфликтующие с вашим приложением:

# Вывести зарезервированные диапазоны портов
netsh int ipv4 show excludedportrange protocol=tcp

Если ваш порт попадает в зарезервированный диапазон, выберите другой порт для приложения.

Дополнительно: постоянные туннели и пользовательские домены

Запуск fxTunnel как фонового процесса

На Windows можно запустить fxTunnel в фоновом режиме через Start-Process:

# Запуск fxTunnel в фоне
Start-Process -NoNewWindow -FilePath "fxtunnel" -ArgumentList "http", "8080"

Для более надёжной настройки рассмотрите запуск fxTunnel как Windows-сервиса через NSSM (Non-Sucking Service Manager) или как задачу планировщика, запускаемую при входе в систему.

Пользовательские домены

Бесплатный тариф назначает случайный поддомен при каждом запуске. Для стабильных URL – эндпоинтов вебхуков, URI перенаправления OAuth, общих ссылок для разработки – используйте пользовательский домен:

fxtunnel http 8080 --domain=dev.yoursite.com

Пользовательские домены, инспектор запросов и повтор (replay) доступны от $5/мес. Инспектор показывает каждый входящий запрос в реальном времени – незаменимо при отладке вебхуков. От $10/мес. доступно 10+ одновременных туннелей для микросервисных архитектур.

Инспектор трафика

Встроенный инспектор трафика позволяет просматривать, фильтровать и повторять HTTP-запросы, проходящие через туннель. На Windows это особенно полезно, поскольку инструменты вроде tcpdump недоступны из коробки. Подробный обзор – в статье «Инспектор трафика: отладка запросов в реальном времени».

Лучшие практики туннелирования на Windows

Следуйте этим рекомендациям, чтобы избежать типичных проблем при туннелировании на Windows:

• Используйте WSL2 для Linux-стеков. Если ваше приложение предназначено для Linux в продакшене, разрабатывайте и туннелируйте из WSL2. Это устраняет кросс-платформенные сюрпризы и соответствует вашему продакшен-окружению.
• Храните проекты в Linux-файловой системе WSL2. Файлы в /mnt/c/ (примонтированный диск Windows) имеют значительно худшую производительность I/O. Храните код в ~/projects/ внутри WSL2 для быстрой сборки и быстрых ответов туннеля.
• Закрывайте туннели, когда они не нужны. Нажмите Ctrl+C, когда закончите работу. Открытый туннель — это открытая дверь к вашей машине. Это касается всех ОС, но на Windows процесс туннеля может пережить закрытие терминала, если запущен в фоне.
• Используйте тестовые данные. Никогда не подключайте туннель к продакшен-базе данных и не используйте боевые API-ключи. Это универсальное правило, но его стоит повторить, учитывая, как легко fxTunnel позволяет открыть любой порт.
• Выбирайте fxTunnel вместо SSH-туннелей на Windows. SSH-туннелирование на Windows требует SSH-клиента, удалённого сервера, ручного проброса портов и не создаёт HTTPS-URL. fxTunnel делает всё одной командой. Почему – разобрано в статье «SSH-туннели vs современные инструменты».

FAQ

Можно ли запустить fxTunnel на Windows без WSL?

Да – он поставляется как самостоятельный .exe без внешних зависимостей. Скачайте через PowerShell командой Invoke-WebRequest или поставьте через go install. Работает напрямую в PowerShell и Command Prompt, WSL и Docker не нужны.

Как пробросить туннель к сервису внутри WSL2 из Windows?

Два варианта. Проще всего поставить fxTunnel внутри WSL2 и запустить его там – сервисы WSL2 привязаны к localhost внутри виртуальной машины. Альтернатива – запустить fxTunnel на Windows и указать IP-адрес WSL2 (узнать его можно командой wsl hostname -I).

Блокирует ли Windows Firewall fxTunnel?

Как правило, нет. fxTunnel использует исходящее TLS-соединение на порту 443, которое Windows Firewall разрешает по умолчанию. Корпоративные файрволы или групповые политики, блокирующие неизвестные исходящие подключения, могут потребовать явного исключения для fxtunnel.exe.

Можно ли использовать fxTunnel с Docker Desktop на Windows?

Да. Docker Desktop пробрасывает порты контейнеров на localhost точно так же, как на Linux. Запустите контейнер с -p 8080:80, затем fxtunnel http 8080 в PowerShell – трафик пойдёт в контейнер. Можно и наоборот – запустить fxTunnel внутри контейнера через docker-compose. Больше сценариев – в статье «Docker + туннель».

Почему туннель показывает connection refused, если сервер работает в WSL2?

WSL2 – это полноценная виртуальная машина Linux со своим сетевым стеком, и сервисы на 127.0.0.1 внутри неё не видны из Windows автоматически. Решение: запустите fxTunnel внутри WSL2, либо привяжите сервис к 0.0.0.0 и укажите IP-адрес WSL2. На Windows 11 с mirrored networking эта проблема уходит сама.