Короткий ответ по самой частой причине и потом подробный чек‑лист для диагностики/исправления.
Частая причина
- WireGuard на Windows создаёт виртуальный интерфейс через драйвер Wintun. Если конфигурация содержит «неправильный» Endpoint (например просто ":<порт>") или если WireGuard не может инициализировать драйвер (прав/подпись драйвера/конфликт/антивирус), то интерфейс может не появиться при активации туннеля. В вашей схеме часто помогает просто указать явный локальный адрес (127.0.0.1:<порт> или [::1]:<порт]) вместо ":<порт>" и запускать wstunnel до поднятия интерфейса.
Что проверить и как диагностировать (шаги по порядку)
1. Локальный слушатель wstunnel
- Убедитесь, что wstunnel на клиенте реально слушает тот порт на localhost до включения интерфейса.
- Команда (PowerShell/CMD): netstat -anob | findstr :<порт>
- Если не слушает — WireGuard не сможет отправить UDP на локальный прокси.
2. Endpoint в конфиге WireGuard
- Замените Endpoint = :<порт> на Endpoint = 127.0.0.1:<порт> или Endpoint = [::1]:<порт>.
- Пустой хост (":port") иногда парсится некорректно в Windows GUI/сервисе — это частая причина «невидимости» интерфейса.
3. Проверить наличие/состояние виртуального адаптера (Wintun)
- В Device Manager -> Network adapters ищите адаптер Wintun / WireGuard.
- PowerShell: Get-NetAdapter | Where-Object {$_.InterfaceDescription -like '*wintun*' -or $_.Name -like '*WireGuard*'}
- Если драйвер отсутствует или неинициализируется — переустановите WireGuard (запуск установщика от имени администратора). Иногда нужно отключить антивирус/защиту от установки драйверов.
4. Права и сервисы
- Запускайте WireGuard GUI с правами администратора (или используйте tunnel service).
- Посмотрите сервисы: sc queryex "WireGuardTunnel$<Имя_туннеля>" — статус должен быть RUNNING при активном туннеле.
- Логи Windows: Event Viewer → Windows Logs → System/Application — ищите ошибки от WireGuard/Wintun.
5. Логи WireGuard / wg
- Выполните: "C:\Program Files\WireGuard\wg.exe show" (или просто wg show, если в PATH) — посмотрите Latest handshake, transfer.
- В GUI WireGuard можно посмотреть статус туннеля — какие ошибки отображаются при попытке включить.
6. Правила брандмауэра / антивирус
- Убедитесь, что локальный UDP трафик на 127.0.0.1:<порт> не блокируется.
- Иногда продукты безопасности блокируют создание виртуального адаптера или взаимодействие с драйвером — временно отключите и проверьте.
7. Порядок старта
- В вашей схеме важно: сначала запустить wstunnel client (чтобы локальный прокси слушал), затем активировать WireGuard интерфейс. Попробуйте автоматизировать порядок (скрипт или автозапуск) и проверить.
8. MTU/AllowedIPs/маршруты (если интерфейс создан, но нет связи)
- Если интерфейс создаётся, но handshake не идёт — проверьте MTU (вы ставили 1300), маршруты (AllowedIPs в клиенте/сервере), NAT/iptables на сервере.
- Используйте wg show для диагностики handshake и счетчиков трафика.
9. Сниффинг трафика
- Запустите Wireshark на loopback/локальном интерфейсе/вintun чтобы убедиться, что UDP от WireGuard идёт на локальный порт и ответы приходят.
10. Альтернативы для теста
- Временно замените wstunnel на простую UDP-прокси (socat, udp2raw) чтобы исключить баг в wstunnel.
- Попробуйте указать в Endpoint публичный IP сервера и порт напрямую (на время теста) — если интерфейс создаётся всегда, значит проблема в локальном прокси/Endpoint.
Резюме/рекомендации
- Первое простое действие: в клиентском конфиге поставить Endpoint = 127.0.0.1:<порт> и запускать wstunnel client ДО включения туннеля WireGuard.
- Если интерфейс всё ещё не создаётся — смотреть Device Manager (Wintun), Event Viewer, переустановить WireGuard с правами администратора и временно отключить антивирус.
- Для дальнейшей помощи пришлите: точный вывод wg show после попытки поднять туннель, вывод netstat -anob для локального порта и скрин/вывод из Device Manager (есть ли Wintun).
Если хотите, могу помочь пошагово: скажите что показывает netstat и wg show после попытки поднять туннель, и какой Endpoint вы сейчас используете в клиентском конфиге.