WireGuard на Windows не підключається: 10 виправлень, що вирішують більшість випадків

Швидка діагностика (перевірки 1–2–3)

Коли WireGuard на Windows «не підключається», перестаньте трактувати це як одну проблему.
Зазвичай це одна з трьох вузьких місць: handshake, маршрутизація або розв’язання імен (DNS).
Знайдіть, яке саме — за менше ніж п’ять хвилин — а потім пориньте глибше.

1) Чи є handshake?

• На Windows: WireGuard UI → виберіть тунель → подивіться «Latest handshake».
• На сервері: перевірте wg show на предмет «latest handshake» і лічильників RX/TX.

Відсутній handshake зазвичай означає проблему з портом/фаєрволом/NAT/ключем.
Handshake є, але трафік не йде — зазвичай проблеми з маршрутами, AllowedIPs, NAT/форвардингом або MTU.

2) Якщо handshake є: чи можете ви запінгувати IP (не ім’я)?

• Пропінгуйте IP інтерфейсу WireGuard сервера (наприклад: 10.6.0.1).
• Пропінгуйте IP внутрішнього ресурсу (наприклад: 10.0.10.25).

Якщо ping по IP працює, але імена — ні, це DNS. Якщо ні працює жоден ping, то проблема в маршрутизації/AllowedIPs/фаєрволі/MTU.

3) Якщо IP-и пінгуються: чи виглядає таблиця маршрутів адекватно?

На Windows неправильні маршрути спричиняють мовчанку: трафік виходить через ваш Wi‑Fi, а не через тунель, тоді як тунель гордо показує «Active».
Перевірте маршрути й метрики інтерфейсів, перш ніж звинувачувати WireGuard.

Факти й контекст, що пояснюють дивності

• WireGuard працює лише по UDP. Якщо ваша мережа блокує вихідний UDP або жорстко лімітує його, ви побачите переривчасті handshakes і «примарну» роботу.
• Немає класичної «сесії» для підтримки. WireGuard досить статeless: передає зашифровані пакети; стан — це в основному ключі й мітки часу handshakes. NAT-пристрої, натомість, люблять стан.
• PersistentKeepalive існує переважно для обходу NAT. Це не фіча продуктивності; це тактика виживання для клієнтів за stateful фаєрволами.
• AllowedIPs — це політика маршрутизації. Це не ACL у традиційному сенсі; це вказівка пірінгу, що шифрувати і куди маршрутувати.
• Windows використовує метрики інтерфейсів для вибору маршруту. «Split tunnel» може випадково стати «без тунеля», якщо інший інтерфейс перемагає в рішенні маршрутування.
• Дизайн WireGuard навмисно мінімалістичний. Менше компонентів — менше місць для помилок, якщо тільки ваша інфраструктура не додає складності через NAT, DNS і корпоративні засоби безпеки.
• Мітки часу handshakes можуть вводити в оману. Останній handshake не доводить, що зворотний шлях працює для потрібного вам трафіка (думаємо про асиметричну маршрутизацію, заблокований ICMP або проблеми тільки з DNS).
• Проблеми з MTU старші за більшість VPN-вендорів. Path MTU black hole існують давно; WireGuard просто робить їх помітними, коли ви інкапсулюєте пакети через нестійкі мережі.

Одна «парафразована ідея», яку варто тримати під рукою, приписують Werner Vogels (становлення надійності):
Все ламається, весь час; проектуйте та оперуйте так, ніби відмова — нормальний стан.

10 виправлень (для більшості випадків, без драми)

Виправлення 1: Доведіть, що сервер справді слухає UDP (і на тому порту, що ви думаєте)

Половина випадків «WireGuard на Windows не підключається» — це просто «сервер більше не слухає» або слухає на неправильному інтерфейсі.
Хтось міг змінити порт. Сервіс не перезапустився. Або правило безпеки в хмарі змінилося непомітно.

Що робити: на сервері перевірте порт прослуховування і чи приходять пакети.
Якщо сервер ніколи не бачить вхідного UDP — перестаньте підлаштовувати Windows. Проблема не там.

Виправлення 2: Підтвердьте, що тунель Windows використовує очікуваний endpoint

Користувачі Windows копіюють конфіги, а потім хтось оновлює IP сервера, або DNS змінюється, або endpoint резолвиться по-іншому в корпоративній мережі.
Якщо ваш endpoint — це hostname, ви запросили DNS у історію вашого підключення. Іноді це нормально. Іноді — пейджер о 3:00.

Виправлення 3: Не гадати — перевіряти ключі й співставлення peer-ів на сервері

WireGuard не має логіна/пароля. Тут усе — ключі.
Одна неправильна буква в публічному ключі або повторне використання клієнтського конфігу на різних машинах може спричинити «іноді підключається» — особливо коли два клієнти ділять один ключ і б’ються за той самий слот пірінгу.

Виправлення 4: Виправте AllowedIPs на клієнті (найпоширеніша самозроблена рана)

AllowedIPs вирішує, який трафік іде в тунель. Якщо ваш AllowedIPs не включає те, до чого ви намагаєтесь дістатися, WireGuard працюватиме ідеально, а ви відчуватимете невдачу ідеально.

• Повний тунель: AllowedIPs = 0.0.0.0/0, ::/0
• Розщеплений тунель: включайте лише внутрішні префікси та IP сервера WG, якщо потрібно.

Якщо ваша ціль — «доступ до внутрішніх підмереж, але інтернет локальний» — робіть split tunnel свідомо.
Не робіть напівповний тунель і дивуйтеся, чому виклики Teams поводяться дивно.

Виправлення 5: Виправте конфлікти маршрутів і метрики інтерфейсів на Windows

Вибір маршруту в Windows детермінований, але не обов’язково корисний. Він обирає «найкращий» маршрут за довжиною префікса, метрикою й вартістю інтерфейсу.
Якщо у вас кілька VPN, віртуальних адаптерів або софту безпеки, ви можете отримати таблицю маршрутів, що схожа на органограму: складну й іноді уявну.

Ваше завдання: упевнитися, що інтерфейс WireGuard має маршрути для потрібних вам призначень і що інші інтерфейси їх не перехоплюють.

Виправлення 6: Виправте DNS (бо «VPN впав» часто означає «DNS впав»)

Люди звинувачують WireGuard, коли ping 10.0.0.10 працює, а ping internal-app — ні.
Це DNS. Виправте DNS перш ніж впадати в екзистенційні сумніви.

Якщо ви штовхаєте внутрішні DNS-сервери через конфіг WireGuard, переконайтеся:
(1) ті DNS-сервери досяжні через тунель, і
(2) Windows справді їх використовує на цьому інтерфейсі.

Виправлення 7: Виправте NAT і форвардинг на сервері (handshake без трафіку)

Handshake доводить, що клієнт і сервер можуть обмінюватися зашифрованим керуючим трафіком.
Це не доводить, що сервер може форвардити пакети з тунелю на LAN або інтернет.

Для повного тунелю сервер зазвичай потребує IP-форвардингу і NAT (masquerade) на egress-інтерфейсі.
Для розщепленого тунелю в LAN може знадобитись маршрут на LAN-шлюзі назад до підмережі WireGuard.

Виправлення 8: Виправте MTU («підключається, але все таймаутить» класика)

Проблеми з MTU проявляються так: handshake є, малі ping-и працюють, сайти зависають, RDP/SMB гальмують або лише деякі застосунки працюють.
UDP-інкапсуляція змінює розміри пакетів. Деякі мережі відкидають фрагменти або блокують ICMP «fragmentation needed».
Ви отримуєте path MTU black hole. Приємні часи.

Виправлення 9: Виправте фаєрвол Windows і засоби безпеки, що «інспектують» ваш VPN

Windows Defender Firewall може блокувати адаптер, а корпоративні endpoint-инструменти можуть блокувати або «оптимізувати» UDP.
Якщо ви на керованому ноутбуку, припускайте, що ви не єдиний, хто має думку про мережевий трафік.

Виправлення 10: Вирішіть зсув часу й поламані мережеві примітиви

WireGuard — це не TLS, але час все одно важить у суміжній екосистемі: DNS, перевірка сертифікатів для застосунків у тунелі і кореляція логів.
Також, якщо мережевий стек Windows у дивному стані (застарілі маршрути, поламаний winsock catalog, напіввстановлені віртуальні адаптери), WireGuard звинуватять у злочинах, яких він не вчиняв.

Жарт #1: Індикатор «VPN підключено» — як індикатор посудомийної машини: каже, що пристрій має почуття, але не те, що тарілки чисті.

Практичні завдання з командами (і як вирішувати)

Це завдання, які я реально виконую під час інцидентів. Кожне включає команду, що означає її вивід і рішення, яке треба прийняти.
Команди показані з Linux-підказки сервера, бо більшість WireGuard-серверів — Linux; для перевірки клієнта Windows ми використовуємо GUI плюс серверну «істину».

Завдання 1: На сервері підтвердьте, що WireGuard запущено і слухає

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 2y...serverpub...
  private key: (hidden)
  listening port: 51820

peer: 9Z...clientpub...
  endpoint: 203.0.113.55:61644
  allowed ips: 10.6.0.2/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 18.42 MiB received, 31.10 MiB sent

Значення: Якщо ви бачите listening port і свіжий handshake, WireGuard живий.
Якщо «listening port» відсутній — інтерфейс може бути вимкнений або неправильно налаштований.

Рішення: Немає handshake і немає endpoint? Зосередьтеся на досяжності UDP (фаєрвол/NAT/порт). Handshake є, але передача застигла? Перейдіть до маршрутів/NAT/MTU.

Завдання 2: Перевірте стан сервісу та інтерфейсу

cr0x@server:~$ sudo systemctl status wg-quick@wg0
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled)
     Active: active (exited) since Sat 2025-12-27 09:11:04 UTC; 2h 13min ago
       Docs: man:wg-quick(8)
             man:wg(8)
    Process: 1234 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)

Значення: Active (exited) — це нормально для wg-quick; він налаштовує інтерфейс і виходить.

Рішення: Якщо сервіс failed — виправте конфіг сервера перед тим, як торкатися Windows. Якщо active — продовжуйте.

Завдання 3: Перевірте, що UDP-сокет зв’язаний (помилка невідповідності порту)

cr0x@server:~$ sudo ss -lunp | grep 51820
UNCONN 0      0           0.0.0.0:51820      0.0.0.0:*    users:(("wireguard",pid=1240,fd=6))

Значення: Система слухає UDP 51820 на всіх IPv4-адресах.

Рішення: Якщо слухача немає — виправте wg0 або змініть клієнтський конфіг під фактичний порт.

Завдання 4: Перевірте, що пакети доходять до сервера (доведіть мережевий шлях)

cr0x@server:~$ sudo tcpdump -ni any udp port 51820 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
09:36:11.112233 eth0  IP 198.51.100.44.61644 > 203.0.113.10.51820: UDP, length 148
09:36:16.113901 eth0  IP 198.51.100.44.61644 > 203.0.113.10.51820: UDP, length 148

Значення: Клієнт досягає UDP-порту вашого сервера.

Рішення: Якщо ви не бачите нічого, поки клієнт перемикає тунель — виправляйте периметричні правила фаєрвола, security groups хмари, блокування ISP або адресу endpoint.

Завдання 5: Підтвердьте, що на сервері увімкнено форвардинг

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Значення: IPv4 forwarding увімкнено; це потрібно для маршрутизації з wg0 на інший інтерфейс.

Рішення: Якщо значення 0 і ви очікуєте, що сервер роутитиме трафік — увімкніть це і зробіть персистентним (потім повторіть тест).

Завдання 6: Перевірте правила NAT nftables/iptables для повнотунельних налаштувань

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.6.0.0/24 -o eth0 -j MASQUERADE

Значення: Клієнти з 10.6.0.0/24 маскарадяться через eth0, тож вони можуть дістатися інтернету (або upstream) без явних зворотних маршрутів.

Рішення: Якщо цього правила немає й ви хочете повний тунель для інтернет-егресу — додайте його. Якщо ви плануєте split tunnel до LAN, можливо, краще налаштувати явні маршрути замість NAT.

Завдання 7: Переконайтеся, що сервер має маршрут назад до підмережі клієнта і LAN має маршрут назад (split tunnel)

cr0x@server:~$ ip route
default via 203.0.113.1 dev eth0
10.0.10.0/24 dev br0 proto kernel scope link src 10.0.10.1
10.6.0.0/24 dev wg0 proto kernel scope link src 10.6.0.1

Значення: Сервер знає, що підмережа WireGuard на wg0.

Рішення: Якщо ваша ціль — 10.0.10.0/24 і клієнти не можуть до неї дістатися, упевніться, що LAN знає, як повернути трафік до 10.6.0.0/24 (через цей сервер). Без цього ви отримаєте односторонні потоки і сум.

Завдання 8: Підтвердьте AllowedIPs пірів на сервері (неправильні підмережі, неправильний /32)

cr0x@server:~$ sudo wg show wg0 allowed-ips
9Z...clientpub... 10.6.0.2/32

Значення: Сервер маршрутує 10.6.0.2 до цього піру. Це типовий випадок для адресації клієнтів.

Рішення: Якщо випадково призначено ту саму клієнтську IP кільком пірам або задано /24 одному пиру, це спричинить неправильну маршрутизацію. Виправте адресацію й AllowedIPs.

Завдання 9: Перевірте наявність дублікатів ключів (два пристрої з однаковою конфігурацією)

cr0x@server:~$ sudo wg show wg0 | sed -n '1,120p'
interface: wg0
  public key: 2y...serverpub...
  listening port: 51820

peer: 9Z...clientpub...
  endpoint: 198.51.100.44:61644
  latest handshake: 24 seconds ago
  transfer: 2.10 MiB received, 3.90 MiB sent

peer: 9Z...clientpub...
  endpoint: 203.0.113.200:54321
  latest handshake: 3 seconds ago
  transfer: 2.11 MiB received, 3.91 MiB sent

Значення: Однаковий публічний ключ двічі — тривожний сигнал. Зазвичай ви побачите один запис peer, але endpoint може «перескакувати» між двома IP, коли пристрої змагаються.

Рішення: Видавайте унікальні пари ключів для кожного пристрою. Ніколи не клонуйте конфіги з тим самим приватним ключем між ноутбуками.

Завдання 10: Перевірте досяжність з сервера в тунель (сервер → клієнт)

cr0x@server:~$ ping -c 3 10.6.0.2
PING 10.6.0.2 (10.6.0.2) 56(84) bytes of data.
64 bytes from 10.6.0.2: icmp_seq=1 ttl=128 time=32.1 ms
64 bytes from 10.6.0.2: icmp_seq=2 ttl=128 time=31.7 ms
64 bytes from 10.6.0.2: icmp_seq=3 ttl=128 time=33.0 ms

--- 10.6.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Значення: Сервер може дістатися IP тунелю клієнта. Це позитивний сигнал для маршрутизації й фаєрволу на боці клієнта.

Рішення: Якщо це падає, але handshake є — підозрюйте фаєрвол Windows на адаптері тунелю, або що ICMP блокується. Тестуйте також TCP/UDP потоки.

Завдання 11: Виявлення MTU black hole за допомогою проби «не фрагментувати» (на сервері)

cr0x@server:~$ ping -c 3 -M do -s 1360 10.6.0.2
PING 10.6.0.2 (10.6.0.2) 1360(1388) bytes of data.
From 10.6.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1420)
From 10.6.0.1 icmp_seq=2 Frag needed and DF set (mtu = 1420)
From 10.6.0.1 icmp_seq=3 Frag needed and DF set (mtu = 1420)

--- 10.6.0.2 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2046ms

Значення: Path MTU менший за ваш розмір корисного навантаження; помилка вказує на MTU близько 1420.

Рішення: Встановіть менший MTU на інтерфейсі WireGuard (звично 1280–1420 залежно від шляху). Перевіряйте, поки проба «не фрагментувати» не пройде.

Завдання 12: Перевірте фаєрвол сервера на правила для трафіку wg0

cr0x@server:~$ sudo iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p udp --dport 51820 -j ACCEPT
-A FORWARD -i wg0 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Значення: UDP 51820 дозволено, і форвардинг між wg0 та eth0 дозволений.

Рішення: Якщо правила форвардингу відсутні, handshake може бути, а форвардний трафік — відкинутий. Виправте FORWARD-правила (або еквівалент для nftables) і повторіть тест.

Завдання 13: Підтвердьте досяжність DNS-сервера через тунель (приклад з сервера)

cr0x@server:~$ dig @10.0.10.53 internal-app.example A +time=2 +tries=1
; <<>> DiG 9.18.24 <<>> @10.0.10.53 internal-app.example A +time=2 +tries=1
;; ANSWER SECTION:
internal-app.example. 60 IN A 10.0.10.25

;; Query time: 34 msec

Значення: Внутрішній DNS-сервер відповідає швидко з точки зору мережі сервера.

Рішення: Якщо DNS доступний з сервера, але не з клієнта — зосередьтеся на маршрутизації/зв’язуванні DNS на боці клієнта. Якщо він недоступний і з сервера — виправляйте LAN-маршрути/фаєрволи перш за все.

Завдання 14: Перевірте, що конфіг пірів сервера не «відхилився»

cr0x@server:~$ sudo grep -nE '^\[Interface\]|\[Peer\]|ListenPort|Address|AllowedIPs|PostUp|PostDown' /etc/wireguard/wg0.conf
1:[Interface]
2:Address = 10.6.0.1/24
3:ListenPort = 51820
4:PostUp = iptables -t nat -A POSTROUTING -s 10.6.0.0/24 -o eth0 -j MASQUERADE
5:PostDown = iptables -t nat -D POSTROUTING -s 10.6.0.0/24 -o eth0 -j MASQUERADE
7:[Peer]
8:PublicKey = 9Z...clientpub...
9:AllowedIPs = 10.6.0.2/32

Значення: Ви перевіряєте точні ключі й директиви маршрутизації, які впливають на «підключається/не підключається».

Рішення: Якщо в конфігу є старі PostUp-правила, неправильна назва інтерфейсу або конфліктні AllowedIPs — виправте, перезапустіть wg-quick і перевірте знову.

Жарт #2: Помилки MTU — це такі проблеми, що змушують сумувати за часами, коли мережа ламалася голосно.

Типові помилки: симптом → корінь → виправлення

1) «Тунель активний», але нічого не працює

Симптом: WireGuard UI показує Active; немає сайтів, немає внутрішніх застосунків, пінги не проходять.

Корінь: AllowedIPs не включає потрібні напрямки; або таблиця маршрутів Windows відправляє трафік кудись ще.

Виправлення: Визначтесь: split чи full tunnel, потім налаштуйте AllowedIPs відповідно. Перевірте, що маршрути існують і їх не перекриває інший адаптер через метрику.

2) Handshake ніколи не з’являється (Latest handshake: never)

Симптом: Клієнт перемикається; сервер не показує endpoint і handshake немає.

Корінь: UDP заблоковано, неправильний endpoint/порт, сервер не слухає, відсутнє правило в хмарному фаєрволі або NAT не форвардить.

Виправлення: На сервері виконайте ss -lunp і tcpdump. Якщо пакети не доходять — виправляйте периметр. Якщо доходять, але handshake немає — перевірте ключі й співставлення пірів.

3) Handshake є, але неможливо дістатися ресурсів LAN

Симптом: Latest handshake оновлюється, але внутрішні підмережі недоступні.

Корінь: Відсутній форвардинг/NAT на сервері, або LAN не має маршруту назад до підмережі WireGuard.

Виправлення: Увімкніть IP-форвардинг; додайте NAT для повного тунелю або додайте зворотні маршрути на шлюзі LAN для розщепленого тунелю.

4) IP-з’єднання працює; DNS відмовляє

Симптом: ping 10.0.10.25 працює, але імена не резолвляться; браузери крутяться.

Корінь: Неправильні DNS-сервери в конфігу, Windows не використовує DNS на тунельному інтерфейсі, або DNS-сервери недосяжні через тунель.

Виправлення: Переконайтеся, що IP DNS-сервера входить в AllowedIPs і він досяжний; підтвердіть, що Windows прив’язує DNS до інтерфейсу WireGuard; не штовхайте публічні DNS для внутрішніх зон.

5) Працює на домашньому Wi‑Fi, падає в офісі / готелі

Симптом: Той самий ноутбук, той самий конфіг; на різних мережах — «ніколи handshake» або флапання.

Корінь: Обмежений вихідний UDP, captive portal, дивний symmetric NAT або агресивний таймаут UDP.

Виправлення: Встановіть PersistentKeepalive = 25 на клієнті для мереж за NAT; розгляньте можливість перенесення сервера на більш досяжний порт; підтвердіть, що мережа дозволяє вихідний UDP.

6) Деякі сайти завантажуються; інші зависають; RDP/SMB гальмують

Симптом: Частковий успіх; таймаути; великі завантаження зупиняються.

Корінь: MTU/фрагментація — чорна діра.

Виправлення: Зменшіть MTU на тунелі; тестуйте DF-ping-и й реальний трафік застосунків.

7) «Вчора працювало» після оновлення Windows

Симптом: Після оновлення адаптер зник або трафік блокується.

Корінь: Проблема драйвера, змінений профіль фаєрвола, нова категорія мережі або засіб безпеки застосував політику.

Виправлення: Перевстановіть WireGuard, перевірте правила фаєрвола для адаптера WireGuard, переконайтеся, що адаптер існує й увімкнений.

8) Двоє користувачів не можуть підключитися одночасно

Симптом: Один підключається, інший відвалюється; на сервері flip-ляться endpoints.

Корінь: Спільний приватний ключ клієнта (клонується конфіг).

Виправлення: Унікальні ключі для кожного пристрою; унікальна IP-адреса тунелю на кожен peer; проведіть аудит конфігів на повторне використання.

Контрольні списки / покроковий план

Покроково: від «не підключається» до кореня проблеми

1. Визначте відмову: «Немає handshake» vs «handshake, але немає трафіку» vs «трафік є, але DNS зламаний». Не пропускайте цей крок.
2. Почніть з сервера: виконайте wg show. Підтвердіть порт прослуховування і чи сервер бачить endpoint.
3. Мережевий шлях: запуск tcpdump на UDP-порті під час перемикання тунелю Windows.
4. Ключі й відповідність пірів: перевірте, що публічний ключ пірінга на сервері відповідає публічному ключу клієнта Windows; підтвердіть, що AllowedIPs кожного піра правильні і не перекриваються.
5. Політика маршрутизації: вирішіть: split чи full tunnel. Потім налаштуйте AllowedIPs і NAT/маршрути на сервері відповідно до вибору.
6. Форвардинг/NAT: увімкніть IP-форвардинг; додайте MASQUERADE для повного тунелю; або налаштуйте зворотні маршрути LAN для split tunnel.
7. DNS: переконайтеся, що DNS-сервер доступний через тунель і що Windows використовує його для зон внутрішніх імен.
8. MTU: якщо все «майже працює», протестуйте DF-ping-и і зменшіть MTU.
9. Інструменти безпеки: якщо все вірно, але проблема лишається на керованих кінцях — підозрівайте політики фаєрвол/EDR; залучіть відповідального за політику раніше.
10. Стабілізація: додавайте keepalive лише якщо NAT цього вимагає; документуйте порти, підмережі й відповідальність.

Контрольний список конфігурації (клієнт + сервер)

• Endpoint IP/hostname правильний; порт відповідає тому, що слухає сервер.
• Клієнт має унікальний приватний ключ; сервер містить відповідний публічний ключ пір-у.
• Client AllowedIPs включає напрямки, які ви очікуєте маршрутувати через тунель.
• Server peer AllowedIPs включає IP тунелю клієнта (/32) і не перекривається з іншими peers.
• Сервер має net.ipv4.ip_forward=1, якщо потрібно маршрутувати поза wg0.
• Існують правила NAT/форвардингу для повного тунелю.
• DNS-сервери, які штовхаються до клієнта, досяжні через тунель.
• MTU налаштовано відповідно до шляху; не вважайте значення за замовчуванням безкінечно правильним.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент, спричинений хибним припущенням (DNS «завжди доступний»)

Середня компанія розгорнула WireGuard, щоб інженери мали доступ до внутрішніх панелей. Split tunnel, прості підмережі, все акуратно.
Конфіг штовхав два внутрішні DNS-сервери, бо внутрішні застосунки мали внутрішні імена. Розумно.

В понеділок вранці тикети вибухнули: «VPN підключається, але нічого не працює». Хелпдеск бачив «Active» і радив перезавантажувати.
Перезавантаження нічого не дало, лише відняло у всіх кавову перерву.

Хибне припущення: DNS-сервери доступні з тунелю. Насправді — ні.
Тиждень тому мережа перемістила DNS у інший VLAN і посилила ACL. Підмережа WireGuard не була включена.
Клієнти могли дістатися внутрішніх IP, якщо знали їх, але розв’язання імен провалювалося, і більшість застосунків не робили fallback на IP.

Виправлення було нудне і правильне: або дозволити підмережі WireGuard запитувати DNS (переважно), або штовхати DNS, до якого підмережа має доступ.
Після оновлення ACL «вилка» VPN-інцидент зник миттєво — змін у WireGuard не знадобилось.

Урок: розглядайте DNS як залежність, яку потрібно явно маршрутизувати й дозволяти. У корпоративних мережах DNS рідко «просто є»; його охороняють.

Міні-історія 2: Оптимізація, що повернулася бумерангом (хитрі NAT-шорткати)

Інша команда хотіла повний тунель, щоб ноутбуки йшли через центральний стек безпеки. Вони побудували WireGuard-шлюз VM.
Щоб «оптимізувати», вони написали мінімальне правило NAT і прибрали, що вважали зайвим форвардингом.
Також посилили дефолтні правила фаєрвола, бо безпекові рев’ю люблять обмеження.

В базовому ping-тесті усе працювало. Вони оголосили перемогу і запустили в прод.
Потім трафік застосунків почав падати дивно: деякі HTTPS-сайти відкривалися, інші таймаутили; великі завантаження зависали; оновлення софту ламаються непередбачувано.
Це виглядало як рандомна інтернет-флейксинка — найвитратніший вид флейксинки.

Повернення боєм було двопланове. По-перше: вони не перевірили MTU наскрізь. Інкапсуляція плюс хмарний шлях з дивною MTU створили фрагментаційну чорну діру.
По-друге: «мінімальні» правила фаєрвола дозволяли лише певні напрямки для established return; деякі потоки відкидалися залежно від шляху, який ядро обирало.

Ремедіація була непримітна: явні FORWARD-правила для wg0 ↔ egress, коректне conntrack-оброблення і зниження MTU до тестово безпечного значення.
Продуктивність не погіршилася. Надійність покращилася суттєво — а це той показник продуктивності, про який дбають дорослі.

Урок: «оптимізувати» політику мережі, прибираючи рядки, які ви не розумієте, — це як «оптимізувати» літак, знімаючи болти, імена яких ви не знаєте.

Міні-історія 3: Нудна практика, що врятувала день (унікальні ключі й інвентар пірів)

Глобальна організація мала флот підрядницьких ноутбуків. Підрядники приходили й йшли; пристрої часто перевстановлювали.
Команда VPN ввела нудне правило: кожен пристрій отримує унікальні ключі WireGuard, унікальний IP тунелю і запис в інвентарі.
Ніяких спільних конфігів. Ніякого «просто скопіюй файл Аліси».

Люди скаржилися. Це додаткова робота. Це уповільнило «швидкий доступ».
Але це зробило систему спостережуваною: коли peer з’являвся на сервері, ви знали, який це пристрій. Коли він поводився дивно — можна було безпечно відключити.

Одної п’ятниці підключення почало флапати у групи користувачів. Серверні логи були не дуже говіркі (WireGuard мінімалістичний),
але wg show показував, що endpoint для певного публічного ключа «блукає» швидко.
Цей патерн кричав: «дубльований ключ у побуті».

Оскільки був інвентар, вони ідентифікували пристрій, зв’язалися з власником і обернули ключі без втручання інших користувачів.
Ніякого широкого простою, ніякої масової перконфігурації, ніяких здогадок, який peer де.
Нудна практика окупилася за один полудень.

Урок: унікальність і інвентар — це функції надійності. Вони не здаються фічами, поки не стануть в пригоді.

Питання й відповіді

1) Чому WireGuard на Windows показує «Active», але в мене немає інтернету?

«Active» означає лише, що інтерфейс увімкнений і конфіг завантажено. Це не гарантує правильну маршрутизацію.
Перевірте handshake, потім AllowedIPs і чи маршрутує Windows 0.0.0.0/0 (повний тунель) через WireGuard чи ні.

2) У мене є handshake, але я не можу дістатися внутрішніх мереж. Яке найшвидше пояснення?

Сервер не форвардить трафік з wg0 до LAN, або LAN не має маршруту назад до підмережі WireGuard.
Handshake доводить, що «ми можемо спілкуватися». Це не доводить, що «ми вміємо маршрутувати».

3) Чи потрібен PersistentKeepalive на Windows?

Лише якщо клієнт Windows знаходиться за NAT/фаєрволом, що видаляє неактивні UDP-мапінги. Якщо ви бачите handshakes тільки після відправлення трафіку,
або з’єднання вмирає за кілька хвилин бездіяльності — встановіть PersistentKeepalive = 25 у секції peer на клієнті.

4) Які AllowedIPs використовувати для split tunnel?

Включіть внутрішні мережі, до яких ви хочете мати доступ (наприклад: 10.0.0.0/8 або конкретні /24), плюс інші приватні діапазони, які дійсно потрібні.
Не додавайте 0.0.0.0/0 «про всяк випадок». Це не split tunnel; це передача ваших рішень маршрутизації майбутньому-я.

5) Чому працює на мобільному хотспоті, але не на офісному Wi‑Fi?

Офісні мережі часто обмежують вихідний UDP, мають captive portal або виконують stateful inspection, що швидко таймаутить UDP.
Доведіть це за допомогою серверного tcpdump: якщо пакети з офісної мережі ніколи не доходять, це не проблема конфігу Windows.

6) Чи можуть два ноутбуки Windows використовувати один і той самий конфіг WireGuard?

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

7) Який MTU варто ставити для WireGuard на Windows?

Універсального значення немає. Звичайні стартові безпечні значення — 1420 або 1380; для «ворожих» шляхів 1280 — це «просто працює» значення.
Якщо handshake є, але застосунки зависають — тестуйте PMTU і знижуйте MTU, поки проблеми не зникнуть.

8) Користуватися hostname чи IP для Endpoint?

IP більш детермінований. Hostname прийнятний, якщо DNS надійний і контрольований, але це додає зависимість.
Якщо ви мусите використовувати hostname — переконайтеся, що клієнт Windows може його резолвити в кожній мережі, яка вам важлива (включно з captive portals і закритими DNS).

9) Чому я можу пінгувати WireGuard IP сервера, але не дістатися нічого за ним?

Бо пінг до IP wg0 — це лише прямий хоп тунелю. Дістатися ресурсів за ним вимагає форвардингу і часто NAT або зворотних маршрутів.
Виправте серверний форвардинг, фаєрвол і upstream-маршрути.

10) Чи «менш сумісний» WireGuard з корпоративними мережами, ніж інші VPN?

Часто він більше блокується, бо працює по UDP і його поведінка легко впізнати (не обов’язково за вмістом).
Багато корпоративних середовищ дозволяють лише TLS/443 і вважають довільний UDP підозрілим. Це політика, а не баг WireGuard.

Наступні кроки для стабільності

Якщо ви хочете, щоб WireGuard на Windows знову став нудно надійним, експлуатуйте його як будь-яку продукційну залежність:
вимірюйте реальність (handshake, маршрути, DNS), забезпечте унікальність (ключі, IP) і документуйте модель маршрутизації (split vs full).
Більшість тикетів «не підключається» зникає, коли перестають сприймати клієнтський UI як істину і починають сприймати сервер як джерело істини.

1. Виберіть стандарт: split tunnel чи full tunnel, і зробіть AllowedIPs відповідними.
2. На сервері підтримуйте верифікований базовий набір: wg show, перевірка listener, форвардинг, правила фаєрвола/NAT.
3. Задокументуйте відповідальних: хто контролює DNS, хто контролює периметральні UDP-правила, хто відповідає за політики безпеки кінцевих точок.
4. Коли падає: дотримуйтесь Швидкої діагностики — handshake → досяжність IP → DNS → MTU.

Мета не в тому, щоб «VPN підключався». Мета в тому, щоб «пакети, які вам потрібні, стабільно досягали сервісів, за які ви платите», на мережах, де сидять ваші користувачі.