WireGuard: найпростіше налаштування клієнта на Windows/macOS/Linux (та звичні підводні камені)

1) Ментальна модель: що WireGuard фактично робить на клієнті

WireGuard — це не магічний «перемикач безпечного інтернету». Це дуже маленький, дуже цілеспрямований шматок програмного забезпечення, який створює віртуальний мережевий інтерфейс (зазвичай wg0 на Linux, адаптер «WireGuard Tunnel» на Windows, інтерфейс utun на macOS). Коли тунель увімкнений, ваша ОС направляє частину трафіку в цей інтерфейс. Пір на іншому боці розшифровує і пересилає його далі (часто в корпоративну мережу, іноді — в публічний інтернет).

Три важелі, які ви фактично контролюєте

• Ключі: хто може спілкуватися з ким.
• AllowedIPs: які призначення направляються в тунель (а також як пірі знаходять відповідність на приймаючій стороні).
• Endpoint: де інша сторона знаходиться зараз (і чи NAT дозволить їй залишатися досяжною).

Все, що болить, зазвичай маскується під одне з цього: рішення щодо маршрутизації, поведінка DNS, стан фаєрволу/NAT або MTU. WireGuard прямолінійний: він налаштовує крипто і штовхає пакети. Він не буде обговорювати маршрути як балакучий корпоративний VPN; він не «виправить» DNS, якщо ви цього не вкажете; він не вгадає, чи ви хотіли split tunneling або повний тунель.

Одна корисна операційна установка: сприймайте WireGuard як точково-точковий мережевий кабель, який ви підключаєте й вимикаєте. Якщо пакети не проходять кабелем, перевіряйте по черзі (1) лінк (handshake), (2) L3 маршрутизацію, (3) L4 досяжність, (4) розв’язування імен. У тому ж порядку кожного разу. Ваше майбутнє «я» скаже вам спасибі.

Цитата, щоб не забувати реальність, від John Allspaw (парафраз): Надійність походить від того, як ви реагуєте на відмови, а не від заперечення цих відмов.

Жарт №1: WireGuard — як добре навчений швейцар; тихий, ефективний і зовсім не цікавиться вашими почуттями щодо маршрутизації.

2) Цікаві факти & контекст (щоб ви перестали боротися з інструментом)

Це не тривіалії заради тривіальностей. Вони пояснюють, чому WireGuard поводиться так, як поводиться — і чому деякі «традиційні очікування VPN» тут не працюють.

1. WireGuard створено, щоб бути крихітним: набагато менше рядків коду ніж у класичних VPN-стеках, мета — зменшити поверхню атак і складність експлуатації.
2. За замовчуванням використовує сучасні примітиви: ви не обираєте набори шифрів; протокол обирає вузький сучасний набір (NoiseIK, ChaCha20-Poly1305, Curve25519, BLAKE2s, HKDF).
3. Це VPN рівня 3: він маршрутизує IP-пакети (і може чисто працювати з IPv6). Це не L2-міст, якщо ви самі не побудуєте його зверху.
4. „AllowedIPs“ одночасно маршрутизація й контроль доступу: на приймаючій стороні це відображення, яке вирішує, якому пірі належить розшифрований пакет; перекриття може спричиняти дивну поведінку.
5. Роумінг вбудований: якщо у клієнта змінюється публічна IP (Wi‑Fi → LTE), WireGuard може «йти за вами», щойно побачить автентифікований трафік з нової адреси.
6. Дружність до NAT — не магія: все ще залежить від того, чи живий стан UDP; тому існує PersistentKeepalive.
7. Linux-перший, але кросплатформенна реальність: реалізація в ядрі Linux — еталон продуктивності; інші платформи використовують нативні інтеграції або userspace-реалізації з OS-особливостями.
8. WireGuard швидко став «мейнстрімом» у Linux: його змерджили в ядро Linux (епоха 5.6), тому він відчувається як перший клас на сучасних дистрибутивах.
9. Він навмисно уникає переговорних фіч: немає складності типу IKE. Це добре для людей. Іноді незручно для корпоративних чеклістів.

3) Ключі, пірі та єдиний файл, який має значення

Конфігурація клієнта WireGuard — це невеликий INI-подібний файл. Він має два блоки: [Interface] (ваш локальний віртуальний інтерфейс) і один або більше [Peer] записів (віддалені кінці, до яких ви шифруєте трафік).

Мінімальна конфігурація клієнта (приклад split tunnel)

Це форма, з якої варто починати. Додавайте складність тільки якщо потрібно. Особливо в корпоративних мережах — кожен додатковий рядок це новий спосіб втратити півдня.

cr0x@server:~$ cat wg-client.conf
[Interface]
PrivateKey = <client-private-key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.8.0.0/24, 10.20.0.0/16
PersistentKeepalive = 25

Інтерпретація простими словами для операційника:

• Address: тунельна IP клієнта. /32 — не друкарська помилка; воно означає «цей інтерфейс володіє тільки цією IP», що зменшує випадкову дивну маршрутизацію.
• DNS: який резолвер використовувати, поки тунель увімкнений. Без нього часто буває «пінгуються IP, але імена не працюють».
• AllowedIPs: список для split tunneling. Тільки ці призначення будуть спрямовані в тунель. Якщо ви поставите 0.0.0.0/0 (і, можливо, ::/0), ви тунелюєте все.
• PersistentKeepalive: тримати стан NAT живим для клієнтів за суворим NAT (готелі, LTE). 25 секунд — це поширене «просто працює» значення.

Два правила, що запобігають більшості відмов

1. Не перекривайте AllowedIPs між пірями на одному інтерфейсі, якщо вам подобається невизначений вибір пірів.
2. Визначте split vs full tunnel наперед і зафіксуйте це явно. «Додамо 0.0.0.0/0 і подивимось» — це шлях зламати принтер, VoIP і своє терпіння.

4) Налаштування клієнта на Windows (просто, з типовими пастками)

Рекомендований підхід: офіційний додаток WireGuard для Windows

На Windows будьте нудними: використовуйте офіційний клієнт з UI. Він встановлює адаптер WireGuard Tunnel і керує маршрутами акуратно. Ви можете імпортувати файл конфігурації, вмикати тунель і він переживе перезавантаження без креативних скриптів.

Кроки, що працюють у реальних компаніях

1. Імпортуйте конфіг: використовуйте «Import tunnel(s) from file». Не вводьте ключі вручну. Люди погано поводяться з base64.
2. Назвіть тунель явно: «corp-split» або «prod-breakglass». «test» стає постійним, а потім — вашою ідентичністю.
3. Увімкнюйте on-demand тільки якщо розумієте Windows-мережі: легко створити стан «підключено, але невикористано», коли мережі змінюються.
4. Перевірте поведінку DNS: Windows має довгу історію списків пошуку DNS і пріоритетів резолвера, що роблять несподівані речі при наявності кількох інтерфейсів.

Пастки Windows, які варто очікувати

• Handshake працює, трафік — ні: часто проблема в маршруті або фаєрволі, а не в WireGuard самому по собі. Windows може мати кілька дефолтних маршрутів з метриками, що дивують.
• DNS витоки або неправильний резолвер: якщо не вказали DNS в конфіг, Windows буде продовжувати використовувати те, що йому подобається (часто DNS фізичного NIC).
• Пріоритет адаптерів/метрики: іноді Windows наполягає на відправці трафіку поза тунелем, бо фізичний інтерфейс має кращу метрику.
• Captive portals: готелі та гостьові Wi‑Fi можуть блокувати UDP або вимагати веб-логін; тунель не підніметься, поки портал не буде пройдений.

5) Налаштування клієнта на macOS (додаток проти wg-quick і DNS-підводні камені)

macOS дає два поширені варіанти: офіційний додаток WireGuard (рекомендовано) або командні інструменти (через сторонні пакети). Для більшості, хто хоче надійності, додаток виграє: він інтегрується з системою мережевих розширень macOS і керує життєвим циклом інтерфейсу без потреби робити launch agents підручними засобами.

Користуйтеся додатком, якщо немає вагомої причини ні

Корпоративний Wi‑Fi і часті цикли сну/пробудження — це місце, де «майже працює» VPN-інструмент помирає. Додаток зазвичай краще відновлюється після змін мережі і повторно встановлює стан DNS/маршрутів.

Особливості DNS на macOS

DNS у macOS — це не «один файл, один резолвер». Це стек з резолверами на інтерфейс, доменами пошуку і scoped resolution. Тунель WireGuard може бути увімкнений і функціональний, а ваш браузер усе ще резолвити внутрішні імена через неправильний резолвер через порядок резолвера або відсутність доменів пошуку.

Якщо ваша компанія використовує split DNS (внутрішні домени резолвляться тільки через внутрішні DNS), слід вказати обидва:

• DNS сервер (наприклад, 10.8.0.1), і
• домен(и) пошуку (наприклад, corp.example), якщо ваш клієнт це підтримує.

Без доменів пошуку користувачі вводять короткі імена й отримують публічні відповіді. Це не «помилка користувача»; це передбачуваний результат конфігурації.

Пастка macOS: сон/пробудження і застарілі маршрути

Після пробудження ви можете побачити тунель «підключено», але трафіку немає. Зазвичай це стан UDP або таблиці маршрутів, що не оновилися. Перемикання тунелю часто це виправляє; також допомагає встановлення PersistentKeepalive для роумінгових клієнтів.

6) Налаштування клієнта на Linux (wg-quick, NetworkManager і реалії маршрутизації)

Linux — це середовище, де WireGuard відчувається так, ніби він завжди мав там існувати. У вас є модуль ядра, утиліти wg і wg-quick, який є прагматичним обгортанням, що налаштовує інтерфейс, маршрути й DNS-хуки.

Шлях «просто змусити працювати»: wg-quick

Помістіть конфіг у /etc/wireguard/wg0.conf і виконайте wg-quick up wg0. Оце й усе. Краща частина — це відкатність: wg-quick down wg0 прибирає маршрути і стан інтерфейсу.

Інтеграція з NetworkManager: добре, але знайте, що вона робить

Якщо ви на ноутбуці з NetworkManager, можна імпортувати конфіг WireGuard і дозволити йому керувати тунелем. Це може бути відмінним для роумінгу, але додає ще один шар, який може перезаписувати маршрути або DNS залежно від дистрибутива й версії. При відладці завжди чітко знайте, хто «володіє» інтерфейсом — wg-quick чи NetworkManager — і не обидва одночасно.

Пастки Linux, що кусають досвідчених інженерів

• Взаємодія з політичною маршрутизацією: сучасні системи можуть мати кілька таблиць маршрутів (особливо з контейнерними/мережевими плагінами). Ваші тунельні маршрути можуть опинитися не там, якщо не бути уважним.
• Reverse path filtering: rp_filter може скидати легітимний тунельний трафік в асиметричних сценаріях маршрутизації.
• iptables/nftables NAT: для клієнтських налаштувань це зазвичай неактуально, але якщо клієнт також форвардить трафік або діє як шлюз — потрібно явно налаштовувати NAT і форвардинг.
• systemd-resolved: обробка DNS може дивувати, якщо resolv.conf — це stub і ви очікуєте, що DNS= просто спрацює без потрібних хуків.

7) Практичні завдання: команди, очікуваний вивід, і рішення (12+)

Це ті перевірки, які я реально виконую, коли хтось каже «WireGuard підключено, але нічого не працює». Кожне завдання містить: команду, що означає вивід, і яке рішення слід прийняти далі.

Завдання 1: Підтвердити, що інтерфейс існує і увімкнений (Linux)

cr0x@server:~$ ip link show wg0
7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Значення: Інтерфейс wg0 існує і УВІМКНЕНО. mtu 1420 типовий. state UNKNOWN нормальний для тунелів.

Рішення: Якщо DOWN або відсутній — тунель не піднято. Виправляйте сервіс/UI спочатку. Якщо увімкнений — переходьте до handshake і маршрутизації.

Завдання 2: Перевірити handshake і лічильники трафіку WireGuard

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 5Z5Jw0y5mOQ4rGqgXwq8yW9q0l1bQp3m5G5m6l8P8xk=
  private key: (hidden)
  listening port: 51820

peer: 9sZxq2Qb7D2i2c8p9n5m0tTn0aVY7mXlCkQw1kVv0m4=
  endpoint: 203.0.113.10:51820
  allowed ips: 10.8.0.0/24, 10.20.0.0/16
  latest handshake: 18 seconds ago
  transfer: 12.34 MiB received, 9.87 MiB sent
  persistent keepalive: every 25 seconds

Значення: Маєте недавній handshake і пакети рухаються. Якщо latest handshake — «never», ймовірно проблеми з endpoint/UDP/фаєрволом/NAT.

Рішення: Якщо handshake свіжий але transfer залишився 0 — підозра на маршрути/AllowedIPs/фаєрвол на віддаленій стороні.

Завдання 3: Перевірити тунельну IP клієнта

cr0x@server:~$ ip addr show dev wg0
7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 10.8.0.2/32 scope global wg0
       valid_lft forever preferred_lft forever

Значення: Клієнт має 10.8.0.2/32 призначений. Добре.

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

Завдання 4: Підтвердити встановлені маршрути для AllowedIPs

cr0x@server:~$ ip route show table main | grep wg0
10.8.0.0/24 dev wg0 scope link
10.20.0.0/16 dev wg0 scope link

Значення: Існують маршрути для split-tunnel. Трафік до цих CIDR йде в wg0.

Рішення: Якщо маршрути відсутні — або wg-quick не запустився, або інший менеджер прибрав маршрути, або ви використали спосіб, що не додає їх автоматично. Виправте це перед роботою з DNS.

Завдання 5: Подивитись, який маршрут буде використано для конкретного призначення

cr0x@server:~$ ip route get 10.20.5.10
10.20.5.10 dev wg0 src 10.8.0.2 uid 1000
    cache

Значення: ОС відправить пакети до 10.20.5.10 через wg0.

Рішення: Якщо воно каже dev eth0 (або Wi‑Fi інтерфейс), ваші AllowedIPs/маршрути невірні. Виправляйте маршрути перш ніж «відлагоджувати WireGuard», коли він не використовується.

Завдання 6: Перевірити досяжність по IP (щоб обійти DNS)

cr0x@server:~$ ping -c 2 10.20.5.10
PING 10.20.5.10 (10.20.5.10) 56(84) bytes of data.
64 bytes from 10.20.5.10: icmp_seq=1 ttl=63 time=28.3 ms
64 bytes from 10.20.5.10: icmp_seq=2 ttl=63 time=27.9 ms

--- 10.20.5.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 27.933/28.110/28.288/0.177 ms

Значення: L3 досяжність через тунель працює.

Рішення: Якщо ping по IP не працює але handshake є — підозра на віддалений фаєрвол, відсутні маршрути на сервері або MTU. Якщо ping працює, але імена — ні, переходьте до завдань по DNS.

Завдання 7: Перевірити шлях для TCP-сервісу (бо ICMP бреше)

cr0x@server:~$ nc -vz 10.20.5.10 22
Connection to 10.20.5.10 22 port [tcp/ssh] succeeded!

Значення: TCP/22 доступний; ймовірно дозволено фаєрволом/секьюриті групами.

Рішення: Якщо ping працює, але TCP — ні, у вас проблема на рівні фаєрволу/сервісу, а не «VPN зламався». Ескалюйте до власника сервісу або політики безпеки.

Завдання 8: Перевірити вибір DNS-резолвера (Linux із systemd-resolved)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 7 (wg0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.8.0.1
       DNS Servers: 10.8.0.1

Значення: DNS для wg0 встановлений на 10.8.0.1. Добре.

Рішення: Якщо DNS сервер — все ще ваш Wi‑Fi роутер, очікуйте помилок з внутрішніми іменами і витоків. Виправляйте DNS у конфігу або в налаштуваннях resolved.

Завдання 9: Довести, що внутрішній DNS працює (і куди він йде)

cr0x@server:~$ dig @10.8.0.1 internal-api.corp.example A +short
10.20.5.10

Значення: Внутрішній резолвер повертає внутрішню адресу.

Рішення: Якщо це працює, але звичайний dig internal-api.corp.example падає — проблема в виборі резолвера/доменах пошуку, а не в сервері.

Завдання 10: Перевірити MTU і PMTU blackhole

cr0x@server:~$ ping -M do -s 1380 -c 2 10.20.5.10
PING 10.20.5.10 (10.20.5.10) 1380(1408) bytes of data.
1388 bytes from 10.20.5.10: icmp_seq=1 ttl=63 time=28.9 ms
1388 bytes from 10.20.5.10: icmp_seq=2 ttl=63 time=29.1 ms

--- 10.20.5.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Значення: Принаймні ~1408-байтні ICMP-пакети з DF проходять. Добрий знак.

Рішення: Якщо ви бачите «Frag needed and DF set» або таймаути на більших розмірах — зменште MTU для WireGuard (зазвичай у діапазоні 1280–1420). Проблеми з MTU часто виглядають як «SSH працює, але Git clone зависає» або «веб завантажує лише частину сторінки».

Завдання 11: Підтвердити UDP досяжність до endpoint (на стороні клієнта)

cr0x@server:~$ nc -vu -w 2 vpn.example.net 51820
Connection to vpn.example.net 51820 port [udp/*] succeeded!

Значення: Ваша система може відправляти UDP до того хоста/порту. Це не гарантує відповідей (UDP), але виключає деякі локальні еґрез-блоки.

Рішення: Якщо це падає в корпоративній мережі — можливо потрібна інша еґрез-політика або інший endpoint/порт. Не витрачайте час на налаштування Keepalive, якщо UDP зовсім заблоковано.

Завдання 12: Інспектувати стан фаєрволу (Linux клієнт)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy accept;
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

Значення: Форвардинг скидається за замовчуванням (поширене), але для клієнта це нормально. Input/output accept означає, що сам хост може спілкуватися.

Рішення: Якщо output обмежено, WireGuard може виконувати handshake але трафік до внутрішніх підмереж бути заблокованим. Коригуйте правила акуратно або використайте профіль хост-фаєрволу, що дозволяє тунель.

Завдання 13: Перевірити sysctl, що може ламати маршрутизовані тунелі (rp_filter)

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 1

Значення: Reverse path filtering у «strict» режимі (1). Це може скидати трафік в асиметричних сценаріях.

Рішення: Для нормального клієнта зазвичай це ок. Для складної split маршрутизації або мультіхомінгу розгляньте встановлення у 2 (loose) на релевантних інтерфейсах після оцінки безпекових наслідків.

Завдання 14: Підтвердити, яким файлом DNS ви реально користуєтесь

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jan  2 10:11 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Значення: Ви використовуєте systemd-resolved stub. Редагування /etc/resolv.conf напряму не збережеться і може не робити те, що ви думаєте.

Рішення: Налаштовуйте DNS через resolvectl, NetworkManager або ваш менеджер WireGuard, а не правте вручну stub-файли в надії.

8) Швидкий план діагностики (перші/другі/треті перевірки)

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

Перше: чи тунель реально обмінюється пакетами?

• Перевірте, що інтерфейс існує і увімкнений.
• Перевірте latest handshake і лічильники transfer.
• Якщо handshake — ніколи: зосередьтеся на endpoint, досяжності UDP, NAT і keepalive.

Друге: чи ОС направляє правильний трафік у тунель?

• Підтвердьте наявність маршрутів для ваших призначень (AllowedIPs).
• Виконайте lookup маршруту для відомої внутрішньої IP (ip route get на Linux).
• Якщо трафік не йде в тунель: виправляйте AllowedIPs або конфлікти менеджера маршрутів.

Третє: чи ви можете дістатися до чогось по IP, а потім по імені?

• Ping внутрішньої IP. Потім перевірте TCP-порт (SSH/HTTPS), бо ICMP може бути дозволений, коли TCP ні.
• Якщо IP працює але імена — ні: виправляйте DNS (сервер, домени пошуку, пріоритет резолвера).

Четверте: MTU і «працює для малого трафіку» відмови

• Якщо чат працює, але великі передачі зависають: підозрюйте MTU/PMTU blackhole.
• Зменшіть MTU на клієнтському тунелі і повторіть тест.

П’яте: віддалена сторона (маршрутизація/ NAT/ фаєрвол на сервері)

• Клієнт може лише відправляти зашифровані пакети. Сервер вирішує, чи маршрутує їх далі.
• Якщо handshake і маршрути клієнта в порядку — сервер може не мати маршрутів назад до клієнтської підмережі або скидати форвардний трафік.

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

1) «Підключено», але немає handshake

Симптом: UI клієнта каже активний, але latest handshake — «never».

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

Виправлення: Перевірте endpoint, протестуйте UDP egress, пройдіть логін captive portal, додайте PersistentKeepalive = 25 для роумінгових клієнтів і переконайтесь, що сервер слухає на цьому порті.

2) Handshake працює, але трафік не доходить до внутрішніх мереж

Симптом: Handshake оновлюється, але ви не можете пропінгувати внутрішні IP; лічильники transfer ледь рухаються.

Корінь: AllowedIPs не включає внутрішні підмережі, або маршрути не встановлені, або Windows route metric віддає перевагу фізичному інтерфейсу.

Виправлення: Додайте правильні внутрішні CIDR до AllowedIPs на клієнті. Підтвердіть маршрути. На Windows перевірте таблицю маршрутів і метрики; переконайтесь, що маршрути тунелю більш специфічні при split tunneling.

3) IP-зв’язок працює, але імена не резолвляться

Симптом: Ви можете ping 10.20.5.10, але ssh internal-api не резолвиться.

Корінь: DNS не вказаний, відсутні домени пошуку, systemd-resolved/NetworkManager не застосовують DNS до тунелю, або DNS встановлений, але блокується політикою.

Виправлення: Встановіть DNS = ... в конфіг клієнта і переконайтесь, що ваша платформа застосовує його. На macOS перевірте, чи резолвер тунелю справді використовується. Додайте домени пошуку, де це підтримується.

4) Усе працює, крім «великих» передач (Git, Docker pulls, копіювання файлів)

Симптом: Малі пінги проходять, деякі сайти вантажаться, але великі завантаження зависають або гальмують.

Корінь: MTU/PMTU blackhole; фрагментація блокується десь між клієнтом і сервером.

Виправлення: Зменшіть MTU тунелю (спробуйте 1380, потім 1360, потім 1280). Тестуйте з DF-пінгами. Уникайте різних MTU на різних клієнтах, якщо можливо.

5) Split tunnel випадково став full tunnel

Симптом: Принтер не працює, Zoom поводиться дивно, локальні пристрої зникли, публічна IP змінилася на офісний еґрез.

Корінь: AllowedIPs містить 0.0.0.0/0 (і, можливо, ::/0), або OS додала дефолтний маршрут.

Виправлення: Прибрати default-route AllowedIPs. Якщо потрібна селективна маршрутизація інтернету — робіть це свідомо з policy routing, а не «тимчасовим» дефолтним маршрутом.

6) Два пірі, одне призначення: трафік йде не туди

Симптом: Деякі внутрішні підмережі періодично маршрутизуються до «не того» піра; поведінка змінюється після перепідключення.

Корінь: Перекриття AllowedIPs між пірами на одному інтерфейсі.

Виправлення: Зробіть AllowedIPs несуміжними. Якщо потрібно переключення по відмові — реалізуйте це на вищому рівні; не сподівайтесь на неоднозначність.

7) Працює на Wi‑Fi, але не на LTE/hotspot

Симптом: Вдома все гаразд; на роздачі з телефону handshake раз пройшов і помер.

Корінь: NAT-мапінг спливає швидко; роумінг змінює endpoint; відсутній keepalive.

Виправлення: Встановіть PersistentKeepalive. Переконайтесь, що сервер дозволяє роумінг (більшість дозволяють за замовчуванням). Розгляньте перенесення сервера в мережу з більш стабільною обробкою UDP.

8) Windows каже підключено, але внутрішній трафік йде не тим NIC

Симптом: Існують маршрути, але вони не використовуються; lookup маршруту показує Wi‑Fi інтерфейс.

Корінь: Конкуруючі маршрути й метрики; іноді більш широкий маршрут з кращою метрикою перемагає у Windows.

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

10) Три корпоративні міні-історії (речі, які ви впізнаєте)

Історія A: інцидент через неправильне припущення

Середня компанія розгорнула WireGuard, щоб замінити старілий VPN. Пілот пройшов гладко: інженери на Linux-ноутбуках, чисті домашні мережі, одна внутрішня підмережа. Конфіг використовував split tunneling і внутрішній DNS. Здавалося, успіх.

Потім масове розгортання дісталося Windows-користувачів. Пішли заявки в підтримку: «VPN підключено, внутрішні імена зламалися». Мережна команда припустила, що DNS «йде разом з VPN», бо так поводився старий клієнт. Файли конфігурації WireGuard не мали директиви DNS, бо на пілоті ніхто не помітив — Linux-користувачі вже мали split DNS через інші інструменти.

Операції намагалися «полагодити» це, додаючи записи до hosts для кількох критичних сервісів. Це купило день і створило археологічний сайт: застарілі IP, непослідовна поведінка і зростаюча залежність від того, що мало бути проблемою резолвера.

Реальне виправлення було нудним: явно визначити поведінку DNS у клієнтських конфігах (і додати домени пошуку де потрібно), потім перевірити по ОС, що резолвер дійсно змінюється при піднятті тунелю. Урок не в тому, що WireGuard хитрий. Урок у тому, що ваші очікування успадковані від іншого продукту.

Історія B: оптимізація, що відкотилася

Команда безпеки захотіла зменшити складність еґрезу. Ідея: тунелювати весь трафік ноутбуків через центральний WireGuard-шлюз, а потім застосовувати DLP і логування в одній точці. Звучало логічно: якщо мережа хаотична — загнати її в трубу і назвати це управлінням.

Розгортання «працювало» в тому сенсі, що handshakes були і трафік йшов. Проблеми почалися з усього навколо: затримкочутливі додатки, локальний доступ і все, що залежить від географічно близьких CDN. Відеодзвінки почали відчуватися як далекі egress, і скарги перетворилися на щогодинні питання від керівництва.

Команда «оптимізувала» збільшивши MTU для кращого throughput. На деяких шляхах це допомогло; на інших — створило PMTU blackholes. Тепер у них була подвійна відмова: деякі користувачі відчували загальну повільність, інші — зависання і напівзавантажені сторінки. Тунель не був падним; він був непослідовно зламаним.

План відновлення: припинити видавати один тунель для всіх. Впровадили split tunneling для більшості, full-tunnel лишили для ролей з дійсною потребою, стандартизували консервативний MTU і задокументували, що «full tunnel» ламає. Це не було ідеологічно чисто. Це було операційно розумно.

Історія C: нудна, але правильна практика, що врятувала день

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

Одного понеділка постачальник повідомив про тотальний збій: ні внутрішнього доступу. Клієнт показував «підключено», але трафік додатків помер. Команда не почала здогадуватися. Вони слідували чеклісту: статус handshake, лічильники, lookup маршрутів, розв’язування DNS, потім перевірки MTU. Виявилось, що це не з їхнього боку.

Справжня проблема була вгору по ланцюжку: фаєрвол змінив політику і блокував inbound UDP на порт WireGuard від конкретного ASN партнера. Оскільки вони мали рутинну перевірку, у них були базові «здорові» виводи. Відсутність handshake зробила проблему очевидною і скоротила суперечку з командою фаєрволу.

Виправлення було цільове: корегування політики. Без героїзму. Цінність була не в інструменті; вона була в повторюваній звичці перевірки і спільному визначенні «працює».

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

Контрольний список для клієнта (усі ОС)

1. Отримайте чистий конфіг від серверної сторони (або згенеруйте): приватний ключ клієнта, тунельна IP клієнта, публічний ключ сервера, endpoint і AllowedIPs.
2. Визначте політику тунелю: split tunnel (рекомендується для більшості) або full tunnel (тільки коли це потрібно і ви приймаєте наслідки).
3. Явно вкажіть DNS: внутрішній резолвер і домени пошуку, якщо ваше середовище використовує короткі імена.
4. Додайте keepalive для роумінгових клієнтів: PersistentKeepalive = 25.
5. Підніміть тунель.
6. Перевірте handshake і лічильники.
7. Перевірте маршрути для однієї внутрішньої IP.
8. Перевірте DNS-резолюцію для одного внутрішнього імені.
9. Протестуйте один реальний шлях додатку (HTTPS до внутрішнього endpoint, SSH або те, що критично).
10. Документуйте очікувану поведінку (які підмережі доступні, чи тунелюється інтернет, який DNS має використовуватися).

Покроково для Windows (лише клієнт)

1. Імпортуйте конфіг у додаток WireGuard.
2. Підтвердіть, що AllowedIPs — це те, що ви хочете (split vs full).
3. Переконайтесь, що DNS вказаний, якщо потрібна внутрішня резолюція.
4. Активуйте тунель.
5. Якщо «підключено» але немає користі: перевірте таблицю маршрутів і поведінку DNS перед тим, як торкатися ключів.

Покроково для macOS (лише клієнт)

1. Імпортуйте конфіг у додаток WireGuard.
2. Увімкніть тунель і переконайтесь, що він переживає сон/пробудження.
3. Якщо внутрішні імена не працюють: перевірте, чи резолвер тунелю справді використовується і чи потрібні домени пошуку.
4. Якщо ламається тільки на деяких мережах: додайте keepalive і розгляньте зменшення MTU.

Покроково для Linux з wg-quick

1. Помістіть конфіг у /etc/wireguard/wg0.conf, права доступу суворо.
2. Підніміть тунель.
3. Перевірте handshake і маршрути.
4. Перевірте інтеграцію DNS (systemd-resolved vs реальність resolv.conf).

cr0x@server:~$ sudo install -m 600 wg-client.conf /etc/wireguard/wg0.conf
cr0x@server:~$ sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 10.8.0.0/24 dev wg0
[#] ip -4 route add 10.20.0.0/16 dev wg0
[#] resolvconf -a wg0 -m 0 -x
[#] iptables -I OUTPUT -o wg0 -j ACCEPT

Значення: wg-quick створив інтерфейс, застосував конфіг, додав адресу й маршрути, і спробував DNS-хуки. (Метод хуків залежить від дистрибутива.)

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

Жарт №2: Якщо ваша VPN-проблема зникає, коли ви зменшите MTU — вітаю, ви виявили, що інтернет все ще працює на вібраціях і скотчі.

12) FAQ

Q1: Що насправді робить «AllowedIPs»?

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

Q2: Чи слід використовувати 0.0.0.0/0 на клієнтах?

Тільки якщо ви хочете повний тунель і готові до побічних ефектів (локальний доступ, зсуви геолокації/CDN, затримки, корпоративні вузькі місця). Для більшості інженерних організацій split tunnel більш спокійний в експлуатації.

Q3: Чому я бачу handshake, але немає трафіку?

Бо handshake лише доводить, що два піри можуть обмінюватися автентифікованими повідомленнями. Це не доводить, що ваша ОС направляє трафік в тунель, або що сервер маршрутує трафік далі. Перевірте маршрути, AllowedIPs і серверний forwarding/фаєрвол.

Q4: Чи потрібен мені PersistentKeepalive?

Для роумінгових клієнтів за NAT (більшість ноутбуків поза офісом) — так. Якщо ви на стабільних мережах і завжди ініціюєте трафік — можливо ні. На практиці 25 секунд — дешева страховка.

Q5: Чому DNS продовжує витікати поза тунель?

Бо DNS — це окрема підсистема і ваша ОС може віддавати перевагу резолверу фізичного інтерфейсу, якщо ви явно не вкажете DNS і менеджер клієнта не застосує його правильно. Виправляйте вибір резолвера, а не крипто WireGuard.

Q6: Який правильний MTU для WireGuard?

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

Q7: Чи можна мати кілька пірів в одному клієнтському конфігу?

Так, але будьте дисципліновані: без перекриття AllowedIPs. Якщо потрібен failover — спроєктуйте його явно; не покладайтеся на неоднозначність.

Q8: Чому це працює на Wi‑Fi, але не в готелях?

Готелі люблять captive portals, обмеження UDP і дивні таймаути NAT. Спочатку завершіть автентифікацію порталу, потім використайте keepalive. Якщо UDP повністю заблоковано — потрібна інша мережа або політично погоджений альтернативний endpoint.

Q9: Чи WireGuard «безпечніший» за старі VPN?

Він безпечний при правильній конфігурації і виграє від меншого, більш аудитованого дизайну. Але безпека — це властивість системи: управління ключами, хардінг endpoint і політика маршрутизації важать так само, як і протокол.

Q10: Який найпростіший спосіб уникнути самонанесення збитків?

Тримайте конфіги мінімальними, стандартизуйте шаблони, уникайте перекриваючих AllowedIPs, встановлюйте DNS свідомо і перевіряйте за повторюваним чеклістом. Складність не масштабується; операційні звички масштабується.

13) Практичні наступні кроки

1. Виберіть політику тунелю: split tunnel для більшості користувачів; full tunnel лише для ролей, яким справді потрібен централізований еґрез.
2. Стандартизуйте клієнтський шаблон конфігу: включіть DNS і keepalive за замовчуванням; робіть AllowedIPs явними і задокументованими.
3. Створіть «known-good test»: один ping внутрішньої IP, одна TCP-перевірка сервісу, одне внутрішнє DNS-ім’я. Використовуйте ті самі три тести на Windows/macOS/Linux.
4. Прийміть швидкий план діагностики: handshake → маршрутизація → IP досяжність → DNS → MTU → серверний forwarding.
5. Запишіть, що означає «працює»: доступні підмережі, очікувана поведінка DNS і чи інтернет має тунелюватися. Це запобіжить наступному інциденту через припущення.

Якщо ви зробите все це, WireGuard стане тим, чим обіцяв бути: маленьким, гострим інструментом, що не заважає — допоки не знадобиться, і тоді поводиться передбачувано. Передбачуваність — найкращий комплімент, який можуть отримати продакшн-системи.