Налаштування WireGuard для Windows
У цьому посібнику описано, як налаштувати VPN-тунель WireGuard між двома комп'ютерами з Windows: сервером WireGuard на віддаленому Windows-хості, наприклад Windows VPS, і клієнтом WireGuard на вашому локальному комп'ютері. Коли тунель активний, машини обмінюються даними через зашифроване приватне з'єднання, а за бажанням увесь трафік клієнта можна спрямувати через сервер.
Базове налаштування створює тунель між сервером і клієнтом. Щоб спрямувати через сервер увесь інтернет-трафік клієнта, на сервері додатково потрібен NAT, див. розділ "Налаштування NAT на сервері для повного тунелювання".
Щоб спростити генерацію ключів, у цьому посібнику обидві конфігурації, серверна і клієнтська, створюються в одному застосунку WireGuard, а потім кожен файл конфігурації переноситься на свою машину. Конфігурація сервера працює на сервері, конфігурація клієнта працює на клієнті. Сервер і клієнт завжди розташовані на різних машинах. Так само додається будь-яка кількість додаткових клієнтів.
Перед початком встановіть останню версію WireGuard зі сторінки завантаження WireGuard і на сервер, і на клієнт, і переконайтеся, що маєте права адміністратора на кожній машині.
Схема в цьому посібнику виглядає так:
Server (public IP, listening on UDP 51820) Tunnel address 10.0.0.1/24 | | encrypted WireGuard tunnel | Client Tunnel address 10.0.0.2/32
Створення конфігурації сервера
Запустіть C:\Program Files\WireGuard\wireguard.exe, натисніть Add tunnel і виберіть Add empty tunnel. WireGuard автоматично створить пару ключів. Публічний ключ у верхній частині вікна належить серверу. Він знадобиться пізніше під час налаштування клієнта.

Задайте ім'я тунелю і заповніть секцію інтерфейсу: приватний ключ сервера, порт, на якому WireGuard прийматиме підключення, і внутрішню адресу сервера в тунелі.
[Interface] PrivateKey = # private key of the WireGuard server ListenPort = # port that WireGuard will listen on Address = # internal IP address of the WireGuard server, for example 10.0.0.1/24

Використовуйте для мережі тунелю приватну підмережу, а сервер і всіх клієнтів тримайте в одному діапазоні. Звичайний варіант: 10.0.0.1/24 для сервера і 10.0.0.2/32, 10.0.0.3/32 і так далі для клієнтів. Сервер використовує префікс /24, щоб увесь діапазон тунелю вважався доступним через інтерфейс WireGuard. Кожен клієнт використовує /32, бо клієнт представляє одну адресу, а не підмережу. Клієнт із /24 вважав би весь діапазон розташованим на своєму інтерфейсі і не надсилав би трафік до інших адрес тунелю через тунель.
У конфігурації сервера прапорця Block untunneled traffic (kill-switch) немає. Він з'являється лише в конфігурації клієнта, яка спрямовує весь трафік через тунель, див. розділ "Створення конфігурації клієнта".
Для додаткового захисту можна додати кожному піру спільний ключ (pre-shared key). Згенеруйте його один раз і додайте той самий рядок у відповідну секцію [Peer] і на сервері, і на клієнті:
PresharedKey = # pre-shared key, identical on the server and the client
Згенерувати ключ можна утилітою wg, яка входить до комплекту WireGuard:
"C:\Program Files\WireGuard\wg.exe" genpsk
Створення конфігурації клієнта
Знову натисніть Add tunnel і виберіть Add empty tunnel, тепер для клієнта. Публічний ключ цього тунелю належить клієнту, він потрібен серверу, щоб прийняти клієнта.
Заповніть конфігурацію клієнта:
[Interface] PrivateKey = # private key of the WireGuard client Address = # internal IP address of the WireGuard client, for example 10.0.0.2/32 DNS = 1.1.1.1, 1.0.0.1 [Peer] PublicKey = # public key of the WireGuard server AllowedIPs = # 0.0.0.0/0 for a full tunnel, or 10.0.0.0/24 for a split tunnel Endpoint = # public IP address and port of the WireGuard server PersistentKeepalive = 25
У Endpoint потрібно вказати реальну публічну IP-адресу сервера і порт із параметра ListenPort сервера, а не внутрішню адресу тунелю. Про вибір значення AllowedIPs див. розділ "Розбираємося з AllowedIPs" нижче.
Рядки DNS і PersistentKeepalive необов'язкові. DNS задає DNS-сервери, які використовуються, поки тунель активний, це допомагає уникнути проблем із розпізнаванням імен після підключення. Можна використовувати публічні резолвери, наприклад 1.1.1.1, 1.0.0.1 або 8.8.8.8, 8.8.4.4, або DNS-сервер самої VPN-мережі. PersistentKeepalive = 25 надсилає невеликий пакет кожні 25 секунд і допомагає утримувати з'єднання, коли клієнт перебуває за NAT.
Якщо в конфігурації клієнта один [Peer] і його AllowedIPs містить 0.0.0.0/0 (або ::/0), під полем конфігурації в редакторі тунелю з'являється прапорець Block untunneled traffic (kill-switch). За роздільного тунелю, наприклад AllowedIPs = 10.0.0.0/24, прапорця немає зовсім.
Kill-switch вмикається за замовчуванням, щойно ви вказуєте 0.0.0.0/0. Поки тунель активний, правила брандмауера пропускають лише трафік через тунель, трафік loopback, DHCP і виявлення сусідів IPv6. Усе інше блокується, зокрема пристрої у вашій локальній мережі, наприклад принтери та NAS. Якщо задано рядок DNS, DNS-запити дозволені лише до вказаних у ньому серверів.
Зняття прапорця не просто вимикає налаштування. Редактор переписує AllowedIPs: 0.0.0.0/0 перетворюється на 0.0.0.0/1, 128.0.0.0/1, а ::/0 на ::/1, 8000::/1. Увесь інтернет-трафік і далі йде через тунель, але блокувальні правила брандмауера не створюються. Якщо знову встановити прапорець, повернеться 0.0.0.0/0.

Копіюйте ключі та Endpoint дуже уважно. Найчастіше тунель не підключається через помилку в ключі або неправильний Endpoint.

Додавання клієнта на сервер
Знову відкрийте конфігурацію сервера і додайте секцію [Peer] для клієнта з публічним ключем клієнта з попереднього кроку.
[Peer] PublicKey = # public key of the WireGuard client AllowedIPs = # internal IP address of the client
У конфігурації сервера AllowedIPs має дві ролі. Він повідомляє серверу, яка адреса тунелю належить цьому клієнту, і працює як список маршрутів: будь-який пакет, адресований у ці діапазони, шифрується і надсилається цьому піру. Для одного клієнта це його адреса в тунелі, наприклад 10.0.0.2/32. Якщо з сервера має бути доступна мережа за цим клієнтом, додайте сюди й цю підмережу, наприклад 10.0.0.2/32, 192.168.1.0/24. Це потрібно, лише якщо клієнт слугує шлюзом у свою локальну мережу. Для звичайного доступу до локальних пристроїв клієнта при активному тунелі див. розділ "Доступ до локальної мережі при активному тунелі". Повторіть цей крок для кожного додаткового клієнта.

Налаштування брандмауера Windows на сервері
Сервер має приймати вхідний трафік WireGuard на своєму UDP-порту. Відкрийте Windows Defender Firewall with Advanced Security, виберіть Inbound Rules і натисніть New Rule. Виберіть Port і натисніть Next. Виберіть UDP, введіть порт WireGuard, наприклад 51820, і натисніть Next. Якщо портів кілька, перелічіть їх через кому, наприклад 51820, 51821. Виберіть Allow the connection і натисніть Next. Позначте профілі, до яких застосовується правило. Якщо сервер розміщено в дата-центрі, зазвичай достатньо профілю Public, в інших випадках залиште позначеними Domain, Private і Public. Натисніть Next, дайте правилу зрозуміле ім'я, наприклад WireGuard UDP 51820, і натисніть Finish.
Це вхідне правило потрібне лише на сервері, бо саме сервер приймає вхідні підключення. На VPS також переконайтеся, що провайдер дозволяє вхідний UDP-трафік на цей порт на рівні мережі, а не лише в брандмауері Windows.
Експорт і розгортання конфігурацій
Коли обидві конфігурації готові, натисніть Export all tunnels to zip, виберіть місце і збережіть.

В архіві містяться файли конфігурації всіх тунелів. Розмістіть конфігурацію сервера на сервері і передайте кожному клієнту його власний файл. Якщо на машині багато тунелів, окремий тунель можна експортувати з його контекстного меню. Експорт у zip зручний, коли обидва тунелі створено на одній машині, як у цьому посібнику. Якщо кожна конфігурація створюється одразу на своєму хості, експорт не потрібен, файл можна скопіювати вручну.
На сервері виберіть конфігурацію сервера і натисніть Activate.

На клієнті натисніть Add Tunnel, виберіть файл конфігурації клієнта і відкрийте його.

Потім натисніть Activate.

Перший клієнт налаштовано. Інші клієнти додаються так само: створіть для кожного новий порожній тунель і додайте в конфігурацію сервера відповідну секцію [Peer] з публічним ключем і адресою тунелю цього клієнта, як описано в розділі "Додавання клієнта на сервер".
Якщо ви налаштовуєте WireGuard на віддаленому сервері через RDP, прочитайте розділ "Розбираємося з AllowedIPs", перш ніж активувати тунель, який спрямовує весь трафік. Конфігурація з AllowedIPs = 0.0.0.0/0 може перенаправити власний трафік сервера в тунель і обірвати RDP-підключення.
Перевірка підключення
Після активації тунелю Windows може показувати адаптер WireGuard як "Немає доступу до мережі" або "Немає доступу до Інтернету" в Центрі мереж і спільного доступу. Це очікувана поведінка: Windows не вважає адаптери VPN-тунелів звичайними інтернет-підключеннями, на роботу тунелю це не впливає. Windows визначає цей статус перевіркою підключення, яка звертається до певних адрес Microsoft, тому попередження може з'явитися і тоді, коли ці запити заблоковано або вони не розпізнаються вашим DNS, навіть якщо тунель працює.
Щоб переконатися, що тунель працює, перевірте його статус у клієнті WireGuard. Активний тунель показує статус Active і лічильники переданих даних. Якщо лічильники зростають, тунель передає трафік.
На сервері також можна переконатися, що WireGuard слухає свій UDP-порт, поки тунель активний:
netstat -ano | findstr 51820
У PowerShell те саме:
Get-NetUDPEndpoint -LocalPort 51820
Замініть 51820 на свій порт WireGuard. Якщо нічого не виводиться, тунель не активний або порт відрізняється від указаного в конфігурації сервера.
Потім відкрийте командний рядок і виконайте ping внутрішньої адреси сервера в тунелі:
ping 10.0.0.1
Замініть 10.0.0.1 на внутрішній IP, який ви задали серверу. Якщо сервер відповідає, трафік через тунель проходить. Якщо відповіді немає, спершу перевірте рукостискання: брандмауер Windows Server за замовчуванням блокує вхідний ping, тому відсутність відповіді не завжди означає, що тунель не працює.
Якщо клієнт використовує AllowedIPs = 0.0.0.0/0, можна також перевірити, що трафік іде через тунель:
tracert 8.8.8.8
Першим вузлом має бути внутрішня IP-адреса сервера WireGuard.
Перевірка рукостискання WireGuard
Рукостискання (handshake) найкраще допомагає під час діагностики з'єднання WireGuard. У застосунку WireGuard відкрийте тунель і стежте за полем Latest handshake. На робочому тунелі рукостискання з'являється протягом кількох секунд після активації і потім періодично оновлюється під час передавання даних. Якщо тунель простоює, між рукостисканнями може минути час, коротка перерва нормальна. Якщо поле залишається порожнім, піри не можуть зв'язатися один з одним. Зазвичай це означає неправильний Endpoint, закритий UDP-порт або ключі, що не збігаються.
Рукостискання можна перевірити і з командного рядка утилітою wg, яка входить до комплекту WireGuard:
wg show
У виводі для кожного піра вказано час останнього рукостискання і лічильники переданих даних.
Розбираємося з AllowedIPs
Значення AllowedIPs у конфігурації клієнта визначає, який трафік іде через тунель. Коротко: на клієнті AllowedIPs задає, які пакети надсилаються в тунель, а на сервері задає, які пакети приймаються від конкретного клієнта і куди вони маршрутизуються.
Значення 0.0.0.0/0 спрямовує через тунель увесь трафік, зокрема звичайний веб-серфінг. Використовуйте його, коли потрібен повний захист трафіку. Щоб цей трафік потрапляв в інтернет, сервер має його транслювати, див. розділ "Налаштування NAT на сервері для повного тунелювання" нижче.
Значення на кшталт 10.0.0.0/24 спрямовує через тунель лише трафік внутрішньої мережі, а звичайний інтернет-трафік іде через звичайне підключення. Використовуйте його, коли потрібен доступ лише до певних ресурсів віддаленої мережі.
Можна вказати кілька підмереж через кому, наприклад 10.0.0.0/24, 192.168.1.0/24.
Прапорець Block untunneled traffic (kill-switch) є лише за повного тунелю з 0.0.0.0/0 і встановлений за замовчуванням. Він блокує й локальну мережу. Щоб зберегти доступ до принтерів та інших пристроїв у локальній мережі, див. розділ "Доступ до локальної мережі при активному тунелі".
Значення AllowedIPs = 0.0.0.0/0 надсилає через тунель усі підключення. Якщо застосувати його на віддаленому сервері, яким ви керуєте через RDP, RDP-сесія може обірватися в момент активації тунелю, бо трафік сервера перенаправляється. На сервері, доступному через RDP, маршрутизуйте лише потрібні підмережі і перевірте все з вузьким значенням AllowedIPs, перш ніж переходити на 0.0.0.0/0.
Доступ до локальної мережі при активному тунелі
За роздільного тунелю, наприклад AllowedIPs = 10.0.0.0/24, локальна мережа працює як зазвичай, нічого змінювати не потрібно. Кроки нижче стосуються повного тунелю.
Найпростіший варіант: зняти прапорець Block untunneled traffic (kill-switch) у редакторі клієнтського тунелю. Редактор замінить 0.0.0.0/0 на 0.0.0.0/1, 128.0.0.0/1. Ваша локальна підмережа, наприклад 192.168.1.0/24, має точніший маршрут через фізичний адаптер, тому Windows надсилає трафік локальної мережі напряму, а інтернет-трафік і далі йде через тунель. Зворотний бік: якщо тунель впаде, ніщо не заблокує трафік.
Якщо потрібно гарантувати, що трафік локальної мережі ніколи не потрапить у тунель, явно виключіть локальний діапазон з AllowedIPs. Наприклад, таке значення охоплює всі адреси IPv4, крім 192.168.0.0/16:
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3
Якщо ваша локальна мережа використовує інший діапазон, наприклад 10.x.x.x або 172.16.x.x, розрахуйте список для нього за допомогою калькулятора AllowedIPs і переконайтеся, що підмережа тунелю до нього входить. У цьому значенні немає маршруту /0, тому kill-switch із ним недоступний.
Info Не використовуйте ту саму підмережу для тунелю і локальної мережі. Якщо домашня мережа 10.0.0.0/24, виберіть для тунелю інший діапазон, наприклад 10.8.0.0/24.
Щоб отримати доступ до мережі за сервером, наприклад до офісної мережі 192.168.10.0/24, на сервері нічого додавати не потрібно: він уже має маршрут у власну локальну мережу. На клієнті додайте цю підмережу в AllowedIPs секції [Peer], наприклад AllowedIPs = 10.0.0.0/24, 192.168.10.0/24. Сервер також має пересилати і транслювати цей трафік, див. розділ "Налаштування NAT на сервері для повного тунелювання". Пристрої в цій мережі відповідають на локальну адресу сервера, тому найпростіше повернути відповіді через тунель за допомогою NAT на сервері.
Налаштування NAT на сервері для повного тунелювання
Якщо клієнти використовують AllowedIPs = 0.0.0.0/0 і їхній трафік має справді виходити в інтернет через сервер, сервер має транслювати внутрішні адреси WireGuard у свою зовнішню адресу. У Windows для цього використовується команда New-NetNat, а не скрипти PostUp і PostDown, як у Linux.
Відкрийте PowerShell від імені адміністратора на сервері і виконайте команду, вказавши підмережу тунелю, призначену серверу:
New-NetNat -Name WireGuardNAT -InternalIPInterfaceAddressPrefix 10.0.0.0/24
Замініть 10.0.0.0/24 на свою підмережу тунелю і переконайтеся, що префікс охоплює всі адреси клієнтів. Клієнт поза цим діапазоном, наприклад 10.0.1.2, під правило не потрапить. Активні правила можна переглянути будь-коли:
Get-NetNat
Щоб пізніше видалити правило NAT, виконайте:
Remove-NetNat -Name WireGuardNAT
Якщо клієнти підключаються і рукостискання проходить, але їхній інтернет-трафік однаково не йде через сервер, увімкніть IP-пересилання на інтерфейсах, які беруть участь у маршрутизації, і перевірте знову. Точна форма залежить від версії Windows, наприклад:
Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled
Застосуйте її до зовнішнього інтерфейсу, через який іде інтернет-трафік, і до інтерфейсу WireGuard, використовуючи їхні реальні імена з Get-NetIPInterface.
New-NetNat потребує Windows 10, Windows 11 або Windows Server 2016 і новіших, а в деяких системах для нього потрібно увімкнути компонент Hyper-V, навіть якщо Hyper-V більше ніде не використовується. На деяких тарифах VPS Hyper-V увімкнути не можна, і цей спосіб не працює. Чи достатньо лише New-NetNat, чи потрібно також увімкнути IP-пересилання, може залежати від версії Windows, тому перевірте це на своєму сервері, якщо повне тунелювання не працює.
Усунення несправностей
Тунель активний, але з'єднання із сервером немає. Перевірте, що UDP-порт WireGuard, наприклад 51820, відкритий у брандмауері сервера. Переконайтеся, що публічні ключі правильно скопійовано між конфігураціями сервера і клієнта. Перевірте, що Endpoint у конфігурації клієнта вказує на реальну публічну IP-адресу сервера, а не на внутрішню адресу тунелю.
DNS не працює після підключення. Додайте DNS-сервер у секцію інтерфейсу клієнта:
[Interface] PrivateKey = ... Address = ... DNS = 1.1.1.1, 1.0.0.1
Лічильники пакетів не зростають. Тунель не передає дані. Перевірте, що AllowedIPs правильно задано на обох сторонах, що внутрішні адреси WireGuard не перетинаються з наявною локальною мережею і що ListenPort не зайнятий іншим застосунком.
Прапорець kill-switch не знімається. Редактор переписує AllowedIPs, лише якщо може прочитати всю конфігурацію. Перевірте, що в секції [Peer] вказано коректний публічний ключ, скопійований із сервера, і що кожне налаштування стоїть в окремому рядку, потім спробуйте знову.
Потрібно більше деталей для діагностики проблеми. Відкрийте тунель у застосунку WireGuard і перейдіть на вкладку Log, де записуються рукостискання, помилки та події підключення в момент їх виникнення. Звідти ж журнал можна експортувати, якщо його потрібно комусь передати.
Автозапуск WireGuard після перезавантаження сервера
Щоб тунель продовжував працювати після перезавантажень, встановіть його як службу Windows. Тунель, встановлений як служба, запускається автоматично після перезавантаження. Відкрийте командний рядок або PowerShell від імені адміністратора і виконайте команду, вказавши шлях до файлу конфігурації сервера:
wireguard /installtunnelservice "C:\Program Files\WireGuard\wg_server.conf"
Виконайте цю команду один раз, а не під час кожного запуску. Активація тунелю із застосунку WireGuard зазвичай встановлює ту саму службу, тому в багатьох випадках достатньо один раз його активувати. Щоб пізніше видалити службу, використовуйте ім'я тунелю, тобто ім'я файлу конфігурації без розширення .conf.
wireguard /uninstalltunnelservice wg_server
Щоб перезапустити службу, наприклад після зміни конфігурації, виконайте команду видалення, а потім знову команду встановлення.
Оскільки тунель працює як служба, окреме завдання в Планувальнику завдань не потрібне.
Перезавантажте сервер і переконайтеся, що тунель запускається сам.
