Wireguard windows 7 unable to create wintun interface

WireGuard Server на Windows

Подозреваю, что я не один такой, кто держит дома в режиме 24/7 маленький и тихий системный блок с Windows в качестве сервера, на который можно зайти по RDP (с того же смартфона) и несколько переживает в связи с количеством «неслучайных» попыток к нему подключиться. Задача не новая и вполне себе решаемая, например можно рассмотреть следующие варианты:

Не очень понятно, можно ли зайти со смартфона (для iPhone вероятно понадобится какой-то гибридный RDP клиент).

Поддерживается только TCP, а RDP уже довольно давно умеет использовать преимущества UDP.

Обновления Windows имеют необъяснимое свойство отключать OpenSSH, не знаю с чем это связано, но несколько за год раз такое было.

Настроить VPN непосредственно на маршрутизаторе. В целом, решение рабочее и минусы тут довольно субъективные:

Не хочется вешать на маршрутизатор дополнительную «необязательную» нагрузку.

Открывается дополнительный вектор атаки непосредственно на маршрутизатор.

Требует определенных технических навыков.

Дополнительно установить Raspberry Pi и на нем настроить VPN (можно ещё много чего на ней запустить). До сих пор пользуюсь, отличный вариант, если есть необходимые навыки и немного денег на «малинку».

Скорее для полноты картины, чем для реального домашнего использования, можно установить Hyper-V на нашу машинку с Windows, создать виртуальную машину с Linux и на нем настроить VPN. Как и в предыдущем случае:

Требует определенных технических навыков.

Могут возникнуть проблемы при отключении питания (виртуальная машина окажется в состоянии Saved и VPN будет недоступен).

Ну и наконец, можно установить сервер VPN непосредственно на Windows. Выбор конкретного VPN дело глубоко личное, но мне последние пару лет посчастливилось изрядно поработать с WireGuard и даже реализовать специализированного клиента для Wandera, в связи с этим выбор был очевиден.

Предварительные изыскания

Я думаю, это ни для кого не новость, что WireGuard уже больше года как включен в основную ветку ядра Linux. С Windows не все так радужно, однако в силу специфики протокола официальный WireGuard для Windows вполне себе выполняет функцию сервера, ему не хватает только NAT. Благодаря Henry Chang и его вдохновленному им micahmo примерно известно как сделать это стандартными средствами Windows. Честно говоря, процесс выглядит немного сложновато, хотя надо отдать должное micahmo, который его частично автоматизировал. Помимо этого, меня заинтересовал следующий комментарий под оригинальным постом:

I have a Win10 machine that I plan to use as a wireguard server. This machine has a main internet network adapter + OpenVPN client connection that is used for selected routes.
If I understand correctly described above wireguard VPN setup will only allow my wireguard clients to access main internet interface but not the OpenVPN connection, please correct me I’m wrong.
Is there a way for a wireguard client to use all available connections and honor existing routes configuration on wireguard server?

Думаю, что полный перевод не требуется, суть состоит в том, чтобы WireGuard использовал для выхода не какой-то один определенный интерфейс (это единственный вариант с Windows Internet Connection Sharing), а тот из них который определен согласно действующей таблице маршрутизации.

Итак, сформулируем задачу

Максимально упростить процесс установки и настройки WireGuard. Давление на компании предоставляющие услуги VPN нарастает и, согласитесь, было бы неплохо, если бы любой пользователь Windows мог бы:

Настроить WireGuard на сервере расположенном облаке, не погружаясь в особенности реализации. Я не призываю к обходу блокировок уважаемого Роскомнадзора, но это так же может быть необходимо, чтобы обойти географические ограничения на какие-то продукты или услуги. Например, до недавнего времени, Ghidra нельзя было скачать с российского IP адреса. Сайт и сейчас вас не пустит, но сам дизассемблер можно скачать с Github. Или цена (валюта расчетов) на авиабилеты может варьироваться в зависимости от страны, с IP которой Вы зашли на сайт авиакомпании. Или можем вспомнить недавнюю историю с «неофициально» ввезенными телевизорами Samsung, у которых «неожиданно» отключилась функция Smart TV. Вернуть телевизор к нормальной жизни можно было только подключив его через европейский VPN. И это только то, что я сходу смог вспомнить.

Установить WireGuard на домашнем Windows сервере и получить постоянный защищенный доступ в собственную сеть и пользоваться ВСЕМИ сервисами доступными ему дома независимо от того в какой точке мира он находится. Например, понравилась мне Яндекс Станция (это не реклама, я действительно их довольно много приобрел для себя, для семьи, в подарки друзьям), да так, что я даже одну привез на Тенерифе. И тут выяснилась удивительная подробность, Яндекс-музыка работает за границей, а вот КиноПоиск ссылается на географические ограничения и отказывается работать. Было бы обидно, но настроил WireGuard клиента на роутере Keenetic и подключил Яндекс станцию через домашний VPN в России. А еще не так уж давно я проделывал что-то подобное для Amazon Fire Stick, чтобы нормально пользоваться подпиской Prime. Могу ошибаться, но кажется где-то читал, что и сам WireGuard был изначально придуман, чтобы смотреть американский Netflix из Австралии.

Использовать некую альтернативу Internet Connection Sharing со всем уважением к имеющейся сетевой конфигурации.

WireSock Gateway

Основная работа выполняется сервисом Wiresock Service, который поддерживает два режима работы: NAT и Proxy.

Первый это классический NAT, сервис включает маршрутизацию (для некоторых типов соединений начиная с Windows 7 встроенная маршрутизация не работает, и они маршрутизируются «вручную»), определяет внешний интерфейс «по умолчанию» на котором и занимается подменой адресов во входящих/исходящих пакетах. Получает почти то же самое, что дает встроенный Internet Connection Sharing, но без ограничений на адреса клиентской сети.

Таким образом, основные задачи вроде бы выполнены. И если к проекту будет интерес, то ему есть куда развиваться, например:

На данный момент (v.1.0.2.4) отсутствует поддержка IPv6.

«Белые» IPv4 постепенно становятся редкостью, поэтому хотелось бы организовать работу WireGuard сервера за NAT (или даже multi-NAT) Интернет-провайдера. Здесь правда без внешнего сервиса (с «белым» IP) обойтись не удастся.

Источник

не получается подключиться через wireguard

с клиента на сервер не пингуется

так и должно быть?
Лучше конфиги покажи.
И вот умвр, сервер — сентось7, клиент — джента. Пинги ходят туда-сюда и у тебя должны.

да. Мне бы хотелось, чтобы сервер не знал, где находится клиент до первого коннекта.

Ты прав в том, что если его явно прописать, то пинги начинают ходить. Но у меня клиент потом будет находиться за NAT и я не могу прописать его IP и порт (порт вообще динамический). И не надо советовать делать пробрасывание на NAT, я как раз этого хочу избежать.

думаю, что не при чём. второй так вообще отсутствует.

не лучше, там приватные ключи от дома лежат:

Приватные ключи настоящие, или ты их подправил? Если настоящие, то у тебя похоже публичные ключи не те.

не лучше, там приватные ключи от дома лежат:

Их можно «запикать» типа pkey1, pkey2 и т.д

Ээээ, Семён Семёныч!

Вот смотри, ты сгенерировал на сервере и клиенте пары ключей
на сервере privkey и publickey_server
На клиенте соответственно privkey1 и public_client1

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = privkey ★★★★★ ( 02.07.18 01:44:13 )

да. Мне бы хотелось, чтобы сервер не знал, где находится клиент до первого коннекта.

У тебя какое-то сильно неверное представление. Сервер итак не знает где находится клиент. В файле конфигурации это не указывается. Тем не менее, после установившегося соединения wg show wg0 будет показывать в endpoint откуда клиент пришёл. У тебя там непонятно почему нули, поэтому логично что у тебя соединения нет. Но, у меня например, если клиент не подключен, то endpoint вообще на сервере в выхлопе peer не показывает. Поэтому нули меня удивили.

Вот это у меня в секции [Interface] у клиента лишнее. Не помню уже откуда и зачем оно там осталось.

Источник

windows: CreateTUN: Error registering rings: Error listing NDIS interfaces: no interfaces found #524

The Tailscale service doesn’t start for some Windows users. Logs:

The Error listing NDIS interfaces is from:

Which calls this, which returns the no interfaces found :

The text was updated successfully, but these errors were encountered:

As requested, output of ipconfig /all

@burhan, my logs show that your machine is still running 0.95-0 stuck in a failure loop.

Perhaps our installer is failing to stop the existing running service before installing newer versions.

Can you go manually stop the service, kill the process if needed, and restart or reinstall?

@burhan, I filed #537 for the installer bug.

After a reboot, some progress! Once you dismiss this dialog, the notification tray icon crashes. This is different than the previous version, where the notification tray icon would remain but show that the service isn’t running.

I reinstalled the application, which resulted in the same safesocket.Connect exception as before:

The service is running:

However, the application:

Restarting the service from the services.msc snap-in didn’t raise an error, but the notification tray icon still shows the service is not running.

BTW, little known Windows trick: you can focus those message box dialogs and hit Control-C and even though the text can’t be selected, that Control-C should make a sound and copy the full text to your clipboard which you can paste in here.

This won’t fix the issue, but it makes it have a much more verbose error message with more details.

@burhan, could you try it and paste the error here?

BTW, I hit this myself today. But only once and then it went away. I don’t have a reliable way to reproduce it.

I just got this error myself (running start /w tailscaled-ipn.exe /server in cmd.exe as Administrator). With new logging:

wgengine.NewUserspaceEngine: Error registering rings: Error listing NDIS interfaces: no interfaces found; buflen=1, deviceID=»ROOTNET002″, flags=0x0

Program starting: v0.100.0-106-ged6dd7b94: []string<«Z:installerbinamd64tailscale-ipn.exe», «/subproc», «d50190ab61c3ceb7407b45662c645d6051b2fb99bda508222471680a02b2acf2»>
subproc mode: logid=d50190ab61c3ceb7407b45662c645d6051b2fb99bda508222471680a02b2acf2
srv: 0.9M/0.0M Starting userspace wireguard engine with tun device «Tailscale»
srv: 1.1M/0.0M no TUN failure diagnostics for OS «windows»
srv: 1.1M/0.0M CreateTUN: Error registering rings: Error listing NDIS interfaces: no interfaces found; buflen=1, deviceID=»ROOTNET003″, flags=0x0
srv: 1.1M/0.0M wgengine.New: Error registering rings: Error listing NDIS interfaces: no interfaces found; buflen=1, deviceID=»ROOTNET003″, flags=0x0
srv: 1.1M/0.0M Listening on 127.0.0.1:41112

I notice the deviceID incremented, if that means anything.

So I finally managed to try out a new build, sadly:

However, on another machine that is running a different Windows build (and didn’t have tailscale installed), not such errors.

Working Windows Version: 10.0.20175 Build 20175 (Insider Preview)
Failing Windows Version: 10.0.19042 Build 19042

Update to add the log:

wgengine.NewUserspaceEngine: Error creating interface: GetStringValueWait(NetCfgInstanceId) failed: Timeout waiting for registry value

I upgraded Tailscale yesterday to 0.100.0-107 (gcef402bc9) and got the same error on my Windows 10 Box (10.0.18363.959).

On another system (Win10: 10.0.18363.900) the error is not present with the same Tailscale version. May it have anything to do with the fact that the erroring system uses Hyper-V? Or another change in the erroring system is that it has a wireless card with no IP-Stack. This is due to the fact that the card just connects to the WiFi and the VMs are using bridging to get their IPs.

If I manually stop the Windows service and restart it (and the GUI) the error disappears.

I was getting this error on one of my machines as well:

What fixed it for me was to change the IPv6 registry setting from 0xFF to 0x20 according to this article from Microsoft.
https://support.microsoft.com/en-us/help/929852/guidance-for-configuring-ipv6-in-windows-for-advanced-users

This was the only difference I could find between two of my machines. Hope this helps!

Источник

Wireguard windows 7 unable to create wintun interface

TUN Device Driver for Windows

This is a layer 3 TUN driver for Windows 7, 8, 8.1, and 10. Originally created for WireGuard, it is intended to be useful to a wide variety of projects that require layer 3 tunneling devices with implementations primarily in userspace.

Wintun is deployed as a platform-specific wintun.dll file. Install the wintun.dll file side-by-side with your application. Download the dll from wintun.net, alongside the header file for your application described below.

Include the wintun.h file in your project simply by copying it there and dynamically load the wintun.dll using LoadLibraryEx() and GetProcAddress() to resolve each function, using the typedefs provided in the header file. The InitializeWintun function in the example.c code provides this in a function that you can simply copy and paste.

With the library setup, Wintun can then be used by first creating an adapter, configuring it, and then setting its status to «up». Adapters have names (e.g. «OfficeNet») and types (e.g. «Wintun»).

After creating an adapter, we can use it by starting a session:

Then, the WintunAllocateSendPacket and WintunSendPacket functions can be used for sending packets (used by SendPackets in the example.c code):

And the WintunReceivePacket and WintunReleaseReceivePacket functions can be used for receiving packets (used by ReceivePackets in the example.c code):

Some high performance use cases may want to spin on WintunReceivePackets for a number of cycles before falling back to waiting on the read-wait event.

You are highly encouraged to read the example.c short example to see how to put together a simple userspace network tunnel.

The various functions and definitions are documented in the reference below.

#define WINTUN_MAX_POOL 256

Maximum pool name length including zero terminator

#define WINTUN_MIN_RING_CAPACITY 0x20000 /* 128kiB */

Minimum ring capacity.

#define WINTUN_MAX_RING_CAPACITY 0x4000000 /* 64MiB */

Maximum ring capacity.

#define WINTUN_MAX_IP_PACKET_SIZE 0xFFFF

Maximum IP packet size

typedef void* WINTUN_ADAPTER_HANDLE

A handle representing Wintun adapter

typedef BOOL(* WINTUN_ENUM_CALLBACK) (WINTUN_ADAPTER_HANDLE Adapter, LPARAM Param)

Called by WintunEnumAdapters for each adapter in the pool.

Parameters

Returns

Non-zero to continue iterating adapters; zero to stop.

typedef void(* WINTUN_LOGGER_CALLBACK) (WINTUN_LOGGER_LEVEL Level, DWORD64 Timestamp, const WCHAR *Message)

Called by internal logger to report diagnostic messages

Parameters

typedef void* WINTUN_SESSION_HANDLE

A handle representing Wintun session

Determines the level of logging, passed to WINTUN_LOGGER_CALLBACK.

WINTUN_ADAPTER_HANDLE WintunCreateAdapter (const WCHAR * Name, const WCHAR * TunnelType, const GUID * RequestedGUID)

Creates a new Wintun adapter.

Parameters

Returns

If the function succeeds, the return value is the adapter handle. Must be released with WintunCloseAdapter. If the function fails, the return value is NULL. To get extended error information, call GetLastError.

WINTUN_ADAPTER_HANDLE WintunOpenAdapter (const WCHAR * Name)

Opens an existing Wintun adapter.

Parameters

Returns

If the function succeeds, the return value is adapter handle. Must be released with WintunCloseAdapter. If the function fails, the return value is NULL. To get extended error information, call GetLastError.

void WintunCloseAdapter (WINTUN_ADAPTER_HANDLE Adapter)

Releases Wintun adapter resources and, if adapter was created with WintunCreateAdapter, removes adapter.

Parameters

Deletes the Wintun driver if there are no more adapters in use.

Returns

If the function succeeds, the return value is nonzero. If the function fails, the return value is zero. To get extended error information, call GetLastError.

void WintunGetAdapterLuid (WINTUN_ADAPTER_HANDLE Adapter, NET_LUID * Luid)

Returns the LUID of the adapter.

Parameters

DWORD WintunGetRunningDriverVersion (void )

Determines the version of the Wintun driver currently loaded.

Returns

If the function succeeds, the return value is the version number. If the function fails, the return value is zero. To get extended error information, call GetLastError. Possible errors include the following: ERROR_FILE_NOT_FOUND Wintun not loaded

void WintunSetLogger (WINTUN_LOGGER_CALLBACK NewLogger)

Sets logger callback function.

Parameters

WINTUN_SESSION_HANDLE WintunStartSession (WINTUN_ADAPTER_HANDLE Adapter, DWORD Capacity)

Starts Wintun session.

Parameters

Returns

Wintun session handle. Must be released with WintunEndSession. If the function fails, the return value is NULL. To get extended error information, call GetLastError.

void WintunEndSession (WINTUN_SESSION_HANDLE Session)

Ends Wintun session.

Parameters

HANDLE WintunGetReadWaitEvent (WINTUN_SESSION_HANDLE Session)

Gets Wintun session’s read-wait event handle.

Parameters

Returns

BYTE* WintunReceivePacket (WINTUN_SESSION_HANDLE Session, DWORD * PacketSize)

Retrieves one or packet. After the packet content is consumed, call WintunReleaseReceivePacket with Packet returned from this function to release internal buffer. This function is thread-safe.

Parameters

Returns

Pointer to layer 3 IPv4 or IPv6 packet. Client may modify its content at will. If the function fails, the return value is NULL. To get extended error information, call GetLastError. Possible errors include the following: ERROR_HANDLE_EOF Wintun adapter is terminating; ERROR_NO_MORE_ITEMS Wintun buffer is exhausted; ERROR_INVALID_DATA Wintun buffer is corrupt

void WintunReleaseReceivePacket (WINTUN_SESSION_HANDLE Session, const BYTE * Packet)

Releases internal buffer after the received packet has been processed by the client. This function is thread-safe.

Parameters

BYTE* WintunAllocateSendPacket (WINTUN_SESSION_HANDLE Session, DWORD PacketSize)

Allocates memory for a packet to send. After the memory is filled with packet data, call WintunSendPacket to send and release internal buffer. WintunAllocateSendPacket is thread-safe and the WintunAllocateSendPacket order of calls define the packet sending order.

Parameters

Returns

Returns pointer to memory where to prepare layer 3 IPv4 or IPv6 packet for sending. If the function fails, the return value is NULL. To get extended error information, call GetLastError. Possible errors include the following: ERROR_HANDLE_EOF Wintun adapter is terminating; ERROR_BUFFER_OVERFLOW Wintun buffer is full;

void WintunSendPacket (WINTUN_SESSION_HANDLE Session, const BYTE * Packet)

Sends the packet and releases internal buffer. WintunSendPacket is thread-safe, but the WintunAllocateSendPacket order of calls define the packet sending order. This means the packet is not guaranteed to be sent in the WintunSendPacket yet.

Parameters

Источник

WireGuard заработал в режиме ядра WindowsNT

Разработчик WireGuard VPN Джейсон Доненфельд выпустил новую версию WireGuardNT, которая работает в режиме ядра WindowsNT (7, 8.1, 10, 11, 2012, 2016, 2019, 2022). Перенос всего кода в ядро значительно повышает пропускную способность туннеля практически на любых соединениях, особенно по WiFi.

Сравнение производительности различных VPN. Источник: WireGuard

Сравнение производительности WireGuard и OpenVPN. Источник: WireGuard

В январе 2020 года после нескольких лет разработки Линус Торвальдс принял WireGuard в основную ветку ядра Linux 5.6. Линус высоко оценил программу с точки зрения качества кода.

Отзыв Линуса можно заносить в резюме

В обычной версии WireGuard для Windows используется реализация WireGuard на Go в userspace. Она привязывается к виртуальному сетевому устройству, большая часть которого также находится в userspace. Джейсон Доненфельд написал собственный виртуальный сетевой интерфейс Wintun, поскольку существующая реализация tap-windows от OpenVPN оставляет желать лучшего.

Wintun определённо лучше tap-windows: даже в проекте OpenVPN такая замена увеличивает пропускную способность туннеля примерно в полтора раза (с 414 до 737 Мбит/с в клиенте OpenVPN 2, с 652 до 904 в OpenVPN 3, в обоих случаях на 7-гигабитном канале). Но при этом мы всё равно не избавляемся от необходимости постоянных контекстных переключений из пространства ядра (реальный сетевой стек) в пространство пользователя (OpenVPN и wireguard-go).

Поэтому для максимальной производительности VPN желательно перенести в ядро весь стек, включая виртуальный адаптер, криптографию и всё остальное. В Linux для этого создаётся модуль DLKM (Dynamically-Loadable Kernel Module), а в Windows — драйвер устройства в ядре. Кстати, проект WireGuardNT начинался именно как прямой порт WireGuard для ядра Linux.

Архитектура ядра WindowsNT

По словам Доненфельда, кодовая база хорошо срослась с нативным кодом ядра и программными интерфейсами NDIS для сетевых драйверов. В итоге получилась «глубоко интегрированная и высокопроизводительная реализация WireGuard для ядра NT, использующая весь спектр возможностей ядра NT и NDIS».

Устранив переключения контекста, удалось значительно повысить производительность. По независимым тестам Ars Technica, на одном и том же оборудовании WireGuardNT даёт на 10−25% больше пропускной способности, чем wireguard-go и Wintun. Другие тестеры говорят даже о росте производительности в несколько раз (с 95 до 600 Мбит/с по WiFi). Сам Джейсон на тестовой Windows-машине зафиксировал производительность 7,5 Гбит/с по VPN.

Вообще, это интересный пример того, как программист-любитель пишет более качественный код для ядра Windows, чем профессионалы из Microsoft. Интересно, сколько человек работает над функцией Always On VPN в Windows Server?

Источник

I have installed Wireguard on Windows 7-32bit
And set the config:

[Interface]
PrivateKey = *********
Address = 172.22.2.2/24
DNS = 172.22.2.1

[Peer]
PublicKey = *******
AllowedIPs = 0.0.0.0/0
Endpoint = ******:8755
PersistentKeepalive = 45

Pretty sure that the DNS setting does not matter, since I have ‘#’ it and set it to ‘8.8.8.8’ while everything the same.
AllowedIPs neither matters since it was set as ‘172.22.2.1’ & ‘172.22.2.1/24’

It did connect at first, but quickly fails. The pop-up sugguest everything goes wrong from

Unable to set interface addresses, routes, dns, and/or interface settings

Here is the entire log for a single trial of connection:

2020-10-11 14:00:12.436200: [TUN] [OneVPS] Starting WireGuard/0.1.1 (Windows 6.1.7601; 386)
2020-10-11 14:00:12.437200: [TUN] [OneVPS] Watching network interfaces
2020-10-11 14:00:12.445200: [TUN] [OneVPS] Resolving DNS names
2020-10-11 14:00:12.445200: [TUN] [OneVPS] Creating Wintun interface
2020-10-11 14:00:13.938200: [TUN] [OneVPS] Warning: unable to determine Wintun version: The system cannot find the file specified.
2020-10-11 14:00:13.939200: [TUN] [OneVPS] Enabling firewall rules
2020-10-11 14:00:13.998200: [TUN] [OneVPS] Dropping privileges
2020-10-11 14:00:13.998200: [TUN] [OneVPS] Creating interface instance
2020-10-11 14:00:13.999200: [TUN] [OneVPS] Routine: encryption worker - started
2020-10-11 14:00:14.000200: [TUN] [OneVPS] Routine: encryption worker - started
2020-10-11 14:00:14.001200: [TUN] [OneVPS] Routine: decryption worker - started
2020-10-11 14:00:14.001200: [TUN] [OneVPS] Routine: handshake worker - started
2020-10-11 14:00:14.001200: [TUN] [OneVPS] Routine: decryption worker - started
2020-10-11 14:00:14.002200: [TUN] [OneVPS] Routine: event worker - started
2020-10-11 14:00:14.002200: [TUN] [OneVPS] Routine: encryption worker - started
2020-10-11 14:00:14.002200: [TUN] [OneVPS] Routine: decryption worker - started
2020-10-11 14:00:14.002200: [TUN] [OneVPS] Routine: handshake worker - started
2020-10-11 14:00:14.002200: [TUN] [OneVPS] Routine: encryption worker - started
2020-10-11 14:00:14.002200: [TUN] [OneVPS] Routine: decryption worker - started
2020-10-11 14:00:14.002200: [TUN] [OneVPS] Routine: handshake worker - started
2020-10-11 14:00:14.002200: [TUN] [OneVPS] Routine: encryption worker - started
2020-10-11 14:00:14.002200: [TUN] [OneVPS] Routine: decryption worker - started
2020-10-11 14:00:14.003200: [TUN] [OneVPS] Routine: handshake worker - started
2020-10-11 14:00:14.003200: [TUN] [OneVPS] Routine: TUN reader - started
2020-10-11 14:00:14.003200: [TUN] [OneVPS] Routine: encryption worker - started
2020-10-11 14:00:14.003200: [TUN] [OneVPS] Routine: handshake worker - started
2020-10-11 14:00:14.003200: [TUN] [OneVPS] Routine: handshake worker - started
2020-10-11 14:00:14.003200: [TUN] [OneVPS] Routine: encryption worker - started
2020-10-11 14:00:14.003200: [TUN] [OneVPS] Routine: decryption worker - started
2020-10-11 14:00:14.003200: [TUN] [OneVPS] Routine: decryption worker - started
2020-10-11 14:00:14.004200: [TUN] [OneVPS] Routine: handshake worker - started
2020-10-11 14:00:14.004200: [TUN] [OneVPS] Routine: handshake worker - started
2020-10-11 14:00:14.004200: [TUN] [OneVPS] Routine: encryption worker - started
2020-10-11 14:00:14.004200: [TUN] [OneVPS] Routine: decryption worker - started
2020-10-11 14:00:14.004200: [TUN] [OneVPS] Setting interface configuration
2020-10-11 14:00:14.005200: [TUN] [OneVPS] UAPI: Updating private key
2020-10-11 14:00:14.005200: [TUN] [OneVPS] UAPI: Removing all peers
2020-10-11 14:00:14.006200: [TUN] [OneVPS] UAPI: Transition to peer configuration
2020-10-11 14:00:14.006200: [TUN] [OneVPS] peer(WrUw…B4VY) - UAPI: Created
2020-10-11 14:00:14.006200: [TUN] [OneVPS] peer(WrUw…B4VY) - UAPI: Updating endpoint
2020-10-11 14:00:14.007200: [TUN] [OneVPS] peer(WrUw…B4VY) - UAPI: Updating persistent keepalive interval
2020-10-11 14:00:14.008200: [TUN] [OneVPS] peer(WrUw…B4VY) - UAPI: Removing all allowedips
2020-10-11 14:00:14.008200: [TUN] [OneVPS] peer(WrUw…B4VY) - UAPI: Adding allowedip
2020-10-11 14:00:14.008200: [TUN] [OneVPS] Bringing peers up
2020-10-11 14:00:14.015200: [TUN] [OneVPS] Routine: receive incoming IPv6 - started
2020-10-11 14:00:14.016200: [TUN] [OneVPS] Routine: receive incoming IPv4 - started
2020-10-11 14:00:14.016200: [TUN] [OneVPS] UDP bind has been updated
2020-10-11 14:00:14.016200: [TUN] [OneVPS] peer(WrUw…B4VY) - Starting...
2020-10-11 14:00:14.016200: [TUN] [OneVPS] peer(WrUw…B4VY) - Routine: sequential receiver - started
2020-10-11 14:00:14.016200: [TUN] [OneVPS] peer(WrUw…B4VY) - Routine: nonce worker - started
2020-10-11 14:00:14.017200: [TUN] [OneVPS] peer(WrUw…B4VY) - Routine: sequential sender - started
2020-10-11 14:00:14.017200: [TUN] [OneVPS] peer(WrUw…B4VY) - Sending keepalive packet
2020-10-11 14:00:14.017200: [TUN] [OneVPS] Monitoring default v6 routes
2020-10-11 14:00:14.017200: [TUN] [OneVPS] peer(WrUw…B4VY) - Sending handshake initiation
2020-10-11 14:00:14.018200: [TUN] [OneVPS] Binding v6 socket to interface 23 (blackhole=false)
2020-10-11 14:00:14.019200: [TUN] [OneVPS] peer(WrUw…B4VY) - Awaiting keypair
2020-10-11 14:00:14.019200: [TUN] [OneVPS] Setting device v6 addresses
2020-10-11 14:00:14.418200: [TUN] [OneVPS] Monitoring default v4 routes
2020-10-11 14:00:14.418200: [TUN] [OneVPS] Binding v4 socket to interface 23 (blackhole=false)
2020-10-11 14:00:14.419200: [TUN] [OneVPS] Setting device v4 addresses
2020-10-11 14:00:14.546200: [TUN] [OneVPS] Listening for UAPI requests
2020-10-11 14:00:14.546200: [TUN] [OneVPS] Startup complete
2020-10-11 14:00:14.546200: [TUN] [OneVPS] Unable to set interface addresses, routes, dns, and/or interface settings: runNetsh run - exit status 1
2020-10-11 14:00:14.664200: [TUN] [OneVPS] Device closing
2020-10-11 14:00:14.664200: [TUN] [OneVPS] Routine: TUN reader - stopped
2020-10-11 14:00:15.311200: [TUN] [OneVPS] Routine: event worker - stopped
2020-10-11 14:00:15.311200: [TUN] [OneVPS] Routine: receive incoming IPv4 - stopped
2020-10-11 14:00:15.311200: [TUN] [OneVPS] Routine: receive incoming IPv6 - stopped
2020-10-11 14:00:15.311200: [TUN] [OneVPS] Routine: decryption worker - stopped
2020-10-11 14:00:15.311200: [TUN] [OneVPS] peer(WrUw…B4VY) - Stopping...
2020-10-11 14:00:15.311200: [TUN] [OneVPS] Routine: decryption worker - stopped
2020-10-11 14:00:15.312200: [TUN] [OneVPS] Routine: encryption worker - stopped
2020-10-11 14:00:15.312200: [TUN] [OneVPS] Routine: encryption worker - stopped
2020-10-11 14:00:15.312200: [TUN] [OneVPS] Routine: decryption worker - stopped
2020-10-11 14:00:15.312200: [TUN] [OneVPS] Routine: encryption worker - stopped
2020-10-11 14:00:15.313200: [TUN] [OneVPS] Routine: handshake worker - stopped
2020-10-11 14:00:15.313200: [TUN] [OneVPS] Routine: handshake worker - stopped
2020-10-11 14:00:15.313200: [TUN] [OneVPS] Routine: handshake worker - stopped
2020-10-11 14:00:15.313200: [TUN] [OneVPS] Routine: encryption worker - stopped
2020-10-11 14:00:15.313200: [TUN] [OneVPS] Routine: decryption worker - stopped
2020-10-11 14:00:15.313200: [TUN] [OneVPS] Routine: encryption worker - stopped
2020-10-11 14:00:15.313200: [TUN] [OneVPS] Routine: handshake worker - stopped
2020-10-11 14:00:15.313200: [TUN] [OneVPS] Routine: decryption worker - stopped
2020-10-11 14:00:15.313200: [TUN] [OneVPS] Routine: handshake worker - stopped
2020-10-11 14:00:15.314200: [TUN] [OneVPS] Routine: decryption worker - stopped
2020-10-11 14:00:15.314200: [TUN] [OneVPS] Routine: encryption worker - stopped
2020-10-11 14:00:15.314200: [TUN] [OneVPS] Routine: handshake worker - stopped
2020-10-11 14:00:15.314200: [TUN] [OneVPS] Routine: handshake worker - stopped
2020-10-11 14:00:15.314200: [TUN] [OneVPS] Routine: encryption worker - stopped
2020-10-11 14:00:15.314200: [TUN] [OneVPS] Routine: handshake worker - stopped
2020-10-11 14:00:15.314200: [TUN] [OneVPS] Routine: decryption worker - stopped
2020-10-11 14:00:15.314200: [TUN] [OneVPS] Routine: encryption worker - stopped
2020-10-11 14:00:15.314200: [TUN] [OneVPS] Routine: decryption worker - stopped
2020-10-11 14:00:15.315200: [TUN] [OneVPS] peer(WrUw…B4VY) - Routine: nonce worker - stopped
2020-10-11 14:00:15.315200: [TUN] [OneVPS] peer(WrUw…B4VY) - Routine: sequential receiver - stopped
2020-10-11 14:00:15.315200: [TUN] [OneVPS] peer(WrUw…B4VY) - Routine: sequential sender - stopped
2020-10-11 14:00:15.315200: [TUN] [OneVPS] Interface closed
2020-10-11 14:00:15.315200: [TUN] [OneVPS] Shutting down

1 ответ

Hallo Forum Gemeinde,

Ich habe Verbindungsprobleme mit meinen Windows 7 WireGuard Clienten.
Im Einsatz habe ich Windows 7 Ultimate 64-Bit System mit dem neusten WireGuar 0.3.15 Clienten.
Die Instalation ist Fehlerfrei. Nach dem start versuche ich meine xxx.conf Datei und zu Aktivieren. Danach bekomme ich die Fehlermeldung: «Unable to create Wintun interface».
Im Protokoll sehe ich :

Danach habe ich mir die Registry angeschaut. Der gesuchte Eintrag ist da, aber an der falsche Stellen.
Und zwar:
SYSTEMCurrentControlSetServicesTcpipParametersInterfaces{24f411dc-18c9-4c73-805d-5cd723b85929}

Wie kann ich das beeinflussen des der Eintrag in …Adapters geschrieben wird oder aber in …Interfaces gelesen?

Vielen dank im Vorraus für Eure Hilfe
Schönen Tag noch.

Content-Key: 806086708

Url: https://administrator.de/contentid/806086708

Ausgedruckt am: 05.02.2023 um 09:02 Uhr

0

1

ip addr show wg0
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.0.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever

wg show wg0
interface: wg0
  public key: V0pBAEHoT2sgrcGvqoU5HeG/M8QoF5iIm5QvVwd0NnA=
  private key: (hidden)
  listening port: 45000

peer: 4PN7RmgIppO2YUmzQxUp4zIs9AU3XexClI1JJlSDbg8=
  endpoint: 0.0.0.0:0
  allowed ips: 0.0.0.0/0
  latest handshake: 26 minutes, 36 seconds ago
  transfer: 1.55 KiB received, 14.02 KiB sent

ip addr show wg0
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.0.0.2/24 scope global wg0
       valid_lft forever preferred_lft forever

wg show wg0
interface: wg0
  public key: 4PN7RmgIppO2YUmzQxUp4zIs9AU3XexClI1JJlSDbg8=
  private key: (hidden)
  listening port: 39985

peer: V0pBAEHoT2sgrcGvqoU5HeG/M8QoF5iIm5QvVwd0NnA=
  endpoint: 192.168.0.1:45000
  allowed ips: 0.0.0.0/0
  latest handshake: 28 minutes, 57 seconds ago
  transfer: 1.36 KiB received, 55.41 KiB sent
  persistent keepalive: every 25 seconds

ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
^C
--- 10.0.0.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3039ms

ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.164 ms
^C
--- 192.168.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.164/0.164/0.164/0.000 ms