DNS WireGuard не працює через VPN: правильне налаштування DNS у Linux та Windows

November 22, 2025 • February 3, 2026 • Читання: 6 хв • Views: 7

Було корисно?

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

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

Швидка діагностика — план дій

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

1) Доведіть, що тунель працює без DNS

Пропінгуйте відомий IP через тунель (роутер з боку VPN, IP DNS-сервера або VIP сервісу).
Якщо IP-з’єднання не проходить — зупиніться. Це вже не стаття про DNS; це питання маршрутизації/фаєрволу/AllowedIPs.

2) Визначте, яким резольвером ви справді користуєтеся

У Linux: перевірте, чи ви використовуєте systemd-resolved, NetworkManager або простий /etc/resolv.conf.
У Windows: перевірте, чи має адаптер WireGuard DNS-сервери та чи застосовано NRPT.

3) Спостерігайте DNS-пакети

Запустіть захоплення пакетів на інтерфейсі WireGuard і на фізичному інтерфейсі.
Рішення: якщо DNS-запити виходять через неправильний інтерфейс — у вас проблема з маршрутами/політикою; якщо вони йдуть правильно, але немає відповіді — це фаєрвол/ACL/NAT або проблема сервера.

4) Підтвердіть, що DNS-сервер на боці VPN доступний і відповідає

Зверніться до DNS-сервера по IP явно (обійдіть локальний резольвер).
Рішення: якщо прямий запит працює, але нормальне розв’язування — ні, інтеграція вашого ОС із резольвером налаштована неправильно.

5) Перевірте очікування split DNS проти реальності

Чи очікуєте ви, що лише corp.example розв’язується через VPN, а публічний DNS залишається локальним?
Якщо так — вам потрібна доменна маршрутизація (Linux resolved/NetworkManager, Windows NRPT). WireGuard сам по собі не виконує політику за доменами.

Одне сухе правило: не міняйте п’ять речей одночасно. DNS — хитрун; потрібні контрольовані експерименти.

Робоча модель: де ламається DNS з WireGuard

WireGuard навмисно простий і «тупий» (в доброму сенсі). Він шифрує пакети між пірами. Він створює інтерфейс. Він має концепцію «які діапазони IP слід пустити в тунель» (AllowedIPs). І все.

DNS тим часом живе у заплутаному, специфічному для ОС світі:

Додатки звертаються до бібліотеки резольвера.
Бібліотека резольвера консультується з конфігурацією (це може бути файл, демон, мережевий менеджер або усі разом, що сперечаються).
Запити надсилаються на налаштовані DNS-сервери по UDP/TCP 53 (або іноді DoT/DoH, якщо ваша система «просунута» або «проклята»).
Ці пакети слідують за таблицею маршрутів і політиками, як будь-який інший трафік.

Отже «DNS WireGuard не працює» зазвичай означає одне з наступного:

Ваша система ніколи не переключила DNS-сервери, коли тунель піднявся.
Вона переключила, але DNS-пакети все одно маршрутизуються поза тунелем.
Вони йдуть у тунель, але сервер недоступний з цього початкового IP або заблокований.
Split-tunnel плюс корпоративний DNS: вам потрібна доменна маршрутизація, але ви налаштували один глобальний DNS-сервер.
Ваш локальний демон резольвера кешує зайвий мотлох або відмовляється надсилати запити до VPN-DNS через «DNSSEC», «приватність» або «я краще знаю».

Рядок DNS= у wg-quick не чарівний. Це зручний хук, який намагається інтегруватися з ОС. Коли він не вдається — він робить це тихо, як дорослий, що ігнорує запрошення на зустріч.

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

DNS з’явився задовго до сучасних VPN. DNS стандартизований на початку 1980-х; більшість дизайнів VPN з’явилися набагато пізніше, тому «інтеграція DNS» прикручена, а не фундаментальна.
WireGuard навмисно уникає просування DHCP-подібних опцій. Традиційні корпоративні VPN часто надсилають налаштування DNS; у WireGuard немає вбудованого каналу управління для цього.
resolv.conf ніколи не був створений для сучасної складності. Це був простий файл; сучасні системи замінили його демонами, тому що ноутбуки мандрують, а інтерфейси з’являються і зникають.
systemd-resolved ввів DNS за підключенням (per-link). Це робить split DNS розумним на Linux — коли його налаштовано правильно.
Windows давно має політику доменного DNS. NRPT існує здебільшого тому, що підприємства вимагали «ці домени до цих DNS-серверів».
DNS може працювати по UDP або TCP. Багато хто про це забуває, поки UDP-фрагментація не почне падати і раптом «тільки великі запити ламаються».
EDNS0 зробив DNS «більшим» і більш крихким. Великі відповіді означають фрагментацію і проблеми PMTU, що проявляються як «випадкові DNS-збої».
Корпоративний DNS часто блокує рекурсію з «невідомих» підмереж. Якщо тунель дає вам новий адресний простір, а ACL для DNS не оновлено — здається, що DNS вимкнений.

Цитата, тому що вона краще пасує до операцій, ніж мотиваційні плакати:

«Сподівання — це не стратегія.» — приписують Вінсу Ломбарді

Поширені режими відмов: що насправді означає «DNS не працює»

Режим A: DNS ніколи не змінився після підняття тунелю

Типові симптоми: ви можете розв’язувати публічні домени, але не внутрішні; або ви продовжуєте розв’язувати внутрішні імена на публічні адреси (або нічого).

Чому так відбувається: wg-quick не застосував DNS-налаштування, бо ваш дистрибутив використовує менеджер резольвера, з яким wg-quick не вміє говорити (або спробував і зазнав невдачі). Або система відразу перезаписала DNS через NetworkManager/DHCP.

Режим B: DNS змінився, але запити виходять через неправильний інтерфейс

Типові симптоми: система показує налаштований DNS-сервер VPN, але захоплення пакетів показує запити, що виходять через Wi‑Fi.

Чому так відбувається: ваш маршрут до IP DNS-сервера вказує на фізичний шлюз, а не на тунель; або політика маршрутизації відправляє UDP/53 у таблицю за промовчанням.

Режим C: Запити йдуть у тунель, сервер не відповідає

Типові симптоми: tcpdump показує вихідні DNS-пакети на wg0, але відповідей немає.

Чому так відбувається: правила фаєрволу, відсутній NAT на VPN-сервері, ACL DNS-сервера не дозволяє вашу тунельну підмережу, або неправильний вихідний IP через політику маршрутизації.

Режим D: Очікування split tunnel без split DNS

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

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

Режим E: MTU/фрагментація викликає «випадкові» DNS-збої

Типові симптоми: маленькі запити працюють, великі — ні; внутрішні зони з великою кількістю записів падають; DNSSEC спричиняє періодичний біль.

Чому так відбувається: UDP-фрагментація або PMTU-чорні діри по шляху тунелю; WireGuard додає накладні витрати; ваш MTU надто оптимістичний.

Жарт №1: DNS як офісні плітки — швидкий, ненадійний і завжди вибирає найдраматичніший маршрут.

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

Це реальні перевірки, які ви можете виконати в проді та на ноутбуках. Кожне завдання містить: команду, репрезентативний вивід, що це означає, і що робити далі. Виконуйте їх у порядку підозри, а не марнославства.

Завдання 1 (Linux): Перевірте стан інтерфейсу WireGuard і хендшейк пірів

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

peer: q7m2...redacted...
  endpoint: 203.0.113.10:51820
  allowed ips: 10.50.0.0/24, 10.60.0.0/16
  latest handshake: 36 seconds ago
  transfer: 28.31 MiB received, 51.22 MiB sent
  persistent keepalive: every 25 seconds

Що це означає: Хендшейк свіжий; трафік проходить. Проблеми з DNS тепер ймовірно в резольвері/маршрутах, а не в крипто.

Рішення: Якщо хендшейк «ніколи», виправте підключення/ключі/endpoint перед тим, як торкатися DNS.

Завдання 2 (Linux): Підтвердіть, що можете дістати DNS-сервер VPN по IP

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

--- 10.50.0.53 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 21.741/21.913/22.086/0.172 ms

Що це означає: Шлях L3 до DNS-сервера існує. Якщо DNS все ще не працює, підозрюйте фільтрацію UDP/53, конфігурацію резольвера або політику split DNS.

Рішення: Якщо ping не проходить, спочатку перевірте маршрути/AllowedIPs/фаєрвол.

Завдання 3 (Linux): Запитайте DNS-сервер напряму (обхід локального резольвера)

cr0x@server:~$ dig @10.50.0.53 internal.service.corp A +time=2 +tries=1

; <<>> DiG 9.18.24 <<>> @10.50.0.53 internal.service.corp A +time=2 +tries=1
; (1 server found)
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22141
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
internal.service.corp. 60 IN A 10.60.12.34

;; Query time: 28 msec
;; SERVER: 10.50.0.53#53(10.50.0.53) (UDP)
;; WHEN: Sat Dec 27 10:12:11 UTC 2025
;; MSG SIZE  rcvd: 74

Що це означає: DNS-сервер VPN працює. Якщо звичайне розв’язування не працює, ваш ОС не використовує його (або маршрутизація для нормальних запитів неправильна).

Рішення: Піднімайтеся вгору по стеку: конфігурація менеджера резольвера, per-link DNS і перевірки маршрутів/політик.

Завдання 4 (Linux): Подивіться, яким резольвером користується система

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Nov 12 09:01 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Що це означає: Ви на systemd-resolved як stub-резольвер. Ваші реальні DNS-сервери керуються інакше.

Рішення: Використовуйте resolvectl для інспекції per-interface DNS; не «виправляйте» DNS редагуванням stub-файлу.

Завдання 5 (Linux): Інспектуйте per-link DNS через systemd-resolved

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

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

Link 7 (wg0)
    Current Scopes: DNS
         Protocols: -DefaultRoute
       DNS Servers: 10.50.0.53
        DNS Domain: ~corp

Що це означає: Налаштовано split DNS: ~corp спрямовується на 10.50.0.53. Усе решта йде через eth0.

Рішення: Якщо wg0 не має DNS-сервера або маршруту домену, виправте ваш PostUp у wg-quick або профіль NetworkManager.

Завдання 6 (Linux): Перевірте, що маршрут до IP DNS-сервера використовує wg0

cr0x@server:~$ ip route get 10.50.0.53
10.50.0.53 dev wg0 src 10.50.0.2 uid 1000
    cache

Що це означає: Ядро маршрутизуватиме трафік до DNS-сервера через інтерфейс тунелю.

Рішення: Якщо показує dev eth0, у вас витік маршруту: додайте IP DNS-сервера до AllowedIPs і/або виправте політику маршрутизації.

Завдання 7 (Linux): Підтвердіть, до якого DNS-сервера звертається libc (швидкий димовий тест)

cr0x@server:~$ getent hosts internal.service.corp
10.60.12.34     internal.service.corp

Що це означає: Шлях резольверу системи може розв’язати ім’я. Це ближче до «що робитимуть додатки», ніж dig у багатьох середовищах.

Рішення: Якщо getent не вдається, але dig @10.50.0.53 працює, інтеграція ОС з резольвером налаштована неправильно.

Завдання 8 (Linux): Захопіть DNS-трафік на wg0 і на фізичному інтерфейсі

cr0x@server:~$ sudo tcpdump -ni wg0 udp port 53 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:13:02.115693 IP 10.50.0.2.53244 > 10.50.0.53.53: 41249+ A? internal.service.corp. (39)
10:13:02.141220 IP 10.50.0.53.53 > 10.50.0.2.53244: 41249 1/0/0 A 10.60.12.34 (55)

Що це означає: DNS-запити і відповіді проходять через wg0. Маршрути правильні, і сервер відповідає.

Рішення: Якщо ви бачите запити на eth0 — виправте маршрути; якщо ви бачите запити на wg0, але немає відповідей — перевірте фаєрвол/ACL/NAT на віддаленому боці.

Завдання 9 (Linux): Перевірте, чи wg-quick встановив спеціальні правила маршрутизації (policy routing)

cr0x@server:~$ ip rule show
0:      from all lookup local
32764:  from all lookup main
32765:  from all lookup default

Що це означає: Додаткових правил policy routing немає. Це нормально для простих «маршрутизація за призначенням», але split tunneling іноді вимагає більше.

Рішення: Якщо ви намагаєтеся робити складну split маршрутизацію (наприклад «лише DNS через VPN»), розгляньте явні правила або per-link DNS через systemd-resolved.

Завдання 10 (Linux): Пошукайте MTU-проблеми, що можуть ламати більші DNS-відповіді

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

Що це означає: MTU 1420 — загалом безпечне значення. Якщо ви на PPPoE, LTE або в дивних хмарах, можливо, потрібне менше.

Рішення: Якщо великі DNS-відповіді падають, протестуйте з меншим MTU (наприклад, 1380) і перевірте поведінку знову.

Завдання 11 (Windows): Перевірте DNS-налаштування адаптера через PowerShell

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias        ServerAddresses
--------------        ---------------
Wi-Fi                 {192.168.1.1}
WireGuard Tunnel       {10.50.0.53}

Що це означає: Адаптер WireGuard має налаштований DNS-сервер. Це необхідна умова, але не достатня.

Рішення: Якщо адаптер WireGuard не має DNS-сервера, виправте профіль WireGuard для Windows (або використайте NRPT для split DNS).

Завдання 12 (Windows): Подивіться, який DNS-сервер Windows фактично використав для запиту

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName internal.service.corp -Type A -DnsOnly | Format-List"
Name       : internal.service.corp
Type       : A
TTL        : 60
Section    : Answer
IPAddress  : 10.60.12.34
Server     : 10.50.0.53

Що це означає: Windows запитав очікуваний DNS-сервер.

Рішення: Якщо Server показує ваш Wi‑Fi маршрутизатор або публічний DNS — у вас проблеми з метриками інтерфейсу/NRPT/суфіксами.

Завдання 13 (Windows): Перевірте метрики інтерфейсів, які впливають на вибір DNS

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object -First 6 | Format-Table -AutoSize"
ifIndex InterfaceAlias     AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp
------- --------------     ------------- ------------ --------------- ----
25      WireGuard Tunnel   IPv4          1420         5               Disabled
12      Wi-Fi              IPv4          1500         35              Enabled

Що це означає: Нижча метрика зазвичай перемагає. Тут інтерфейс WireGuard пріоритетний, що часто бажано для DNS повного тунелю.

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

Завдання 14 (Windows): Перегляньте правила NRPT (перевірка split DNS)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptRule | Select-Object Namespace,NameServers,DirectAccessDnsServers | Format-Table -AutoSize"
Namespace   NameServers
---------   ----------
.corp       {10.50.0.53}

Що це означає: Запити для *.corp спрямовуються до DNS-сервера VPN незалежно від поведінки DNS за замовчуванням.

Рішення: Якщо вам потрібен split DNS у Windows — NRPT це дорослий підхід. Налаштуйте його свідомо і тестуйте за допомогою Resolve-DnsName.

Правильне налаштування DNS у Linux

Конфігурація DNS у Linux — це не одна система. Це екосистема ввічливих рекомендацій і суперечок між демонами. Ваша мета — вибрати один авторитет і зробити поведінку детермінованою.

Реальність Linux: оберіть свій шлях резольвера

Фактично ви в одній із цих категорій:

systemd-resolved (поширений на Ubuntu, Debian-похідних, Fedora тощо). Найкращий варіант для split DNS при коректній конфігурації.
NetworkManager, який керує DNS (часто інтегрується з resolved; іноді ні).
Openresolv/resolvconf, що записує /etc/resolv.conf. Все ще поширено на мінімальних серверах і в контейнерах.
Статичний /etc/resolv.conf. Добре, поки ви не подорожуєте мережами; тоді це стає місцем пригод.

Що насправді робить wg-quick з DNS=

wg-quick — це shell-скрипт. Коли ви вказуєте DNS=10.50.0.53 у конфігу, він намагається викликати інструменти на кшталт resolvconf або взаємодіяти з resolved через resolvectl залежно від дистрибутива. Якщо цих інструментів нема — DNS може просто не змінитися.

Думка: не покладайтеся на «можливо» інтеграцію. Для ноутбуків інтегруйтеся з платформним мережевим менеджером або resolved явно. Для серверів надавайте перевагу детермінованій конфігурації резольвера, яка переживе перезавантаження і рестарти сервісів.

Коректні конфігурації (оберіть одну)

Налаштування 1: systemd-resolved split DNS (рекомендовано для корпоративних доменів)

Це те, що вам потрібно, якщо вимога: внутрішні домени розв’язуються через VPN DNS; усе інше — через локальну мережу (або публічний резольвер).

WireGuard сам не може робити «доменно-орієнтовані AllowedIPs». Але resolved може робити вибір DNS-сервера за доменом. Ви поєднуєте їх: маршрутуйте IP DNS-сервера в тунель і навчіть resolved, який домен до якого сервера.

Приклад конфігурації WireGuard:

cr0x@server:~$ sudo sed -n '1,120p' /etc/wireguard/wg0.conf
[Interface]
Address = 10.50.0.2/24
PrivateKey = (hidden)
ListenPort = 51820

PostUp = resolvectl dns %i 10.50.0.53; resolvectl domain %i ~corp
PostDown = resolvectl revert %i

[Peer]
PublicKey = (redacted)
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.50.0.0/24, 10.60.0.0/16, 10.50.0.53/32
PersistentKeepalive = 25

Що важливо тут:

AllowedIPs включає внутрішні мережі, які вам потрібні, і IP DNS-сервера (10.50.0.53/32), щоб шлях запитів був однозначним.
resolvectl dns %i задає DNS-сервер для лінку wg0.
resolvectl domain %i ~corp робить його «маршрутом лише для домену», а не глобальним DNS за замовчуванням.
revert прибирає налаштування при зниженні інтерфейсу. Вам потрібне прибирання. Майбутньому вам воно сподобається більше ніж зараз.

Перевірте: після підняття інтерфейсу resolvectl status має показувати wg0 з DNS Domain: ~corp. Потім перевірте трафік tcpdump.

Налаштування 2: systemd-resolved повний тунель DNS (просто, іноді коректно)

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

У термінах resolved: задайте DNS-сервер на wg0 і дозвольте йому бути DNS за замовчуванням (або задайте глобальний DNS). Чистий підхід залежить від інтеграції дистрибутива, але надійний патерн — все ще PostUp/Down з resolvectl, просто без ~corp домену. Можна задати маршрут для «.», але це часто зайве агресивно.

Думка: повний тунель DNS на ноутбуках часто створює дивні збої SaaS, коли корпоративні резольвери фільтрують. Використовуйте split DNS, коли можете.

Налаштування 3: resolvconf/openresolv (поширено на невеликих серверах)

Якщо ваша система не використовує resolved, wg-quick з DNS= може працювати, якщо існує resolvconf. Якщо його немає — ви будете спостерігати, як DNS ніколи не змінюється і дивуватися, за що платите електроенергію.

Встановіть і перевірте інструменти:

cr0x@server:~$ command -v resolvconf || echo "resolvconf not found"
resolvconf not found

Рішення: Якщо ви хочете покладатися на wg-quick DNS — встановіть resolvconf/openresolv. Якщо потрібна детермінована поведінка — управляйте /etc/resolv.conf самостійно або переходьте на resolved.

Приклад wg-quick конфігу з DNS=:

cr0x@server:~$ sudo sed -n '1,80p' /etc/wireguard/wg0.conf
[Interface]
Address = 10.50.0.2/24
PrivateKey = (hidden)
DNS = 10.50.0.53

[Peer]
PublicKey = (redacted)
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.50.0.0/24, 10.60.0.0/16, 10.50.0.53/32
PersistentKeepalive = 25

Підводні камені Linux, що спричиняють «DNS не працює»

Плутанина зі stub resolv.conf: редагування /etc/resolv.conf, коли це символічне посилання на stub, не зробить те, що ви очікуєте.
NetworkManager вас переслідує: він може перезаписувати DNS для підключення. Вирішіть, чи NM володіє DNS; якщо так — налаштовуйте там.
Локальні кешуючі резольвери: unbound або dnsmasq можуть працювати і форвардити до неправильного upstream.
VPN DNS доступний лише через тунель: якщо маршрут до DNS-сервера не в AllowedIPs, система спробує дістатися до нього локально і зазнає невдачі.
Правила вихідного фаєрволу: локальний фаєрвол може блокувати UDP/53 на wg0, бо хтось вважає це «закріпленням».

Правильне налаштування DNS у Windows

Windows у цьому випадку одночасно краща і гірша. Краще тому, що має повноцінні політики (NRPT). Гірше тому, що він «допомагає» з метриками інтерфейсів, списками суфіксів DNS і кешуванням, що виглядає як газлайтинг.

Що насправді змінює клієнт WireGuard для Windows

Додаток WireGuard для Windows створює віртуальний адаптер. Коли ви задаєте DNS у профілі тунелю, він налаштовує DNS-сервери цього адаптера. Чи використовуватиме Windows цей DNS для конкретного запиту — залежить від:

Який інтерфейс обрано для розв’язування імен (метрики та порядок прив’язки).
Чи використовується split DNS через NRPT.
Списки суфіксів пошуку і які імена вважаються «в домені».
Чи виконує запит додаток через системні DNS-API (більшість так) або має власний резольвер (деякі — особлива радість).

Два розумні підходи у Windows

Патерн 1: DNS повного тунелю (просто)

Якщо ви хочете «весь DNS через VPN», зробіть так:

Задайте DNS-сервери адаптера WireGuard у профілі.
Переконайтеся, що адаптер WireGuard має низьку метрику інтерфейсу, щоб бути пріоритетним.
Переконайтеся, що IP DNS-сервера маршрутується через тунель (AllowedIPs містить його).

Це найменша кількість рухомих частин. Воно також найімовірніше буде дратувати користувачів, якщо корпоративний DNS блокує зовнішні запити або повертає «дружні» результати.

Патерн 2: Split DNS з NRPT (рекомендовано для корпоративних зон)

Якщо ви хочете «лише корпоративні зони використовують VPN DNS», використовуйте NRPT. NRPT може цільово застосовувати правила для просторів імен (доменів) і примушувати певні резольвери для цих імен. Це зменшує залежність від метрик інтерфейсів і скорочує випадкову поведінку при перепідключеннях Wi‑Fi.

Створення правила NRPT (приклад):

cr0x@server:~$ powershell -NoProfile -Command "Add-DnsClientNrptRule -Namespace '.corp' -NameServers '10.50.0.53'"

Перевірте:

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptRule | Where-Object Namespace -eq '.corp' | Format-List"
Namespace   : .corp
NameServers : {10.50.0.53}

Перевірте розв’язування і який сервер відповів:

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName internal.service.corp -Type A -DnsOnly | Select-Object Name,IPAddress,Server | Format-Table -AutoSize"
Name                 IPAddress    Server
----                 ---------    ------
internal.service.corp 10.60.12.34  10.50.0.53

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

Типові Windows-специфічні режими відмов

Війна метрик інтерфейсів: Windows може вважати Wi‑Fi «кращим» і використовувати його DNS для всього. Понизьте метрику WireGuard або використайте NRPT.
Розв’язування у багатодомній системі: Windows може пробувати кілька інтерфейсів; результати можуть бути непослідовні, коли один DNS повертає NXDOMAIN, а інший — відповідь.
Невідповідність списку суфіксів пошуку: Користувач вводить internal і очікує internal.corp. Без правильного суфіксу — нічого або неправильний публічний результат.
Додатки, що ігнорують системний DNS: Деякі браузери і агенти використовують власний DNS (DoH). Ваші налаштування VPN-DNS не вплинуть, поки ви не відключите або не контролюєте цю поведінку.

Жарт №2: Налагодження DNS у Windows — хороша кар’єрна інвестиція, бо гарантує зайнятість — переважно для того, хто успадкує вашу машину після перезавантаження.

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

Це ті, що я бачу знову і знову. Вони забирають години, бо «виглядають» як DNS, а насправді це маршрути чи вибір резольвера.

1) «Хендшейк є, але внутрішні імена не розв’язуються»

Симптом: wg show виглядає добре. ping 10.60.12.34 працює. getent hosts internal.service.corp не працює.

Корінь проблеми: ОС не використовує DNS-сервер VPN; інтеграція wg-quick DNS не застосувалась.

Виправлення: У Linux налаштуйте systemd-resolved через resolvectl dns/domain хуки або налаштуйте NetworkManager. У Windows — задайте DNS адаптеру або використайте NRPT.

2) «DNS-сервер встановлений на 10.50.0.53, але таймаутиться»

Симптом: Резольвер вказує VPN DNS, але dig показує таймаути.

Корінь проблеми: Маршрут до IP DNS-сервера не через wg0; AllowedIPs не містить IP DNS-сервера або підмережі, що його містить.

Виправлення: Додайте 10.50.0.53/32 (або підмережу) до AllowedIPs. Перевірте за допомогою ip route get 10.50.0.53.

3) «Лише великі DNS-відповіді падають (або лише деякі домени)»

Симптом: Малі запити працюють, зони з DNSSEC не працюють або TXT-запити помирають.

Корінь проблеми: MTU/фрагментація/PMTU у шляху тунелю.

Виправлення: Зменшіть MTU WireGuard (наприклад, до 1380) і протестуйте. Якщо потрібно, вимушено використайте TCP для діагностики і проаналізуйте захоплення пакетів на предмет фрагментації.

4) «Зовнішній серфінг ламається при підключеному VPN, але внутрішнє працює»

Симптом: VPN увімкнено; корпоративні додатки працюють; публічні сайти зависають або розв’язуються у дивні адреси.

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

Виправлення: Використовуйте split DNS (routing domains у resolved на Linux; NRPT у Windows). Тримайте публічний DNS локальним або використовуйте спеціальний рекурсивний резольвер для зовнішнього трафіку.

5) «CLI інструменти працюють, а браузери — ні»

Симптом: dig і getent працюють, але браузер не може завантажити внутрішні хости.

Корінь проблеми: Браузер використовує DNS-over-HTTPS або власний резольвер; він обходить системний DNS.

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

6) «Вчора працювало, сьогодні ні, а перезавантаження ‘вирішує’»

Симптом: Переривчасте розв’язування; перезавантаження очищає стан.

Корінь проблеми: Невідповідність стану кешу резольвера (systemd-resolved cache, Windows DNS cache) або мерехтіння інтерфейсів, що призводить до неправильного вибору DNS-сервера.

Виправлення: Промийте кеші як діагностику; потім зробіть вибір DNS детермінованим (per-link DNS, NRPT, правильні метрики). Перестаньте ставити перезавантаження як рішення.

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

Міні-історія 1: Інцидент через хибне припущення

Вони розгорнули WireGuard, щоб замінити старий віддалений VPN. План міграції був чистий: тунель піднімається, користувачі отримують доступ до внутрішніх сервісів — готово. Команда протестувала з пінгами і кількома curl по IP. Все виглядало зелено.

Зранку понеділка кількість інцидентів стрибнула. «VPN підключено, але нічого не працює». На виклику перевірили сервер WireGuard. Хендшейки були. Лічильники трафіку рухалися. Тунель не був вимкнений; він був байдужий.

Вбивчим виявилося припущення: хтось вважав, що додати DNS=10.50.0.53 до клієнтської конфігурації означає, що ОС надійно переключиться на резольвер. На деяких Linux-ноутбуках wg-quick не зміг поговорити з локальною системою резольвера. У Windows адаптер мав DNS, але розв’язування імен все одно віддавало перевагу Wi‑Fi DNS через зміну метрики після оновлення драйвера.

Вони виправили це, зробивши вибір DNS явним: per-link конфігурація systemd-resolved на Linux, NRPT правила на Windows для внутрішніх просторів імен. Постмортем не був про WireGuard; він був про «ми тестували підключення, але не тестували розв’язування імен як додаток». Ось справжній урок. Додатки не підключаються до IP, які ви вставляєте в Slack; вони підключаються до імен.

Міні-історія 2: Оптимізація, що відгукнулася боком

Команда безпеки хотіла зменшити DNS-leaks. Мета розумна. Вони вирішили: «примусити весь DNS через VPN». Вони вказали всім клієнтам корпоративний рекурсивний резольвер, доступний лише з тунелю, і вважали роботу виконаною.

Перша проблема: затримка. Віддалені співробітники надсилали кожний DNS-запит через тунель до резольвера, який не був налаштований для глобального навантаження. Серфінг здавався повільним, бо сучасні веб-сторінки викликають лавину DNS-запитів. Друга проблема: надійність. Резольвер часом фільтрував, і коли він гальмував — усе гальмувало.

Потім справжній факап: деякі SaaS-аутентифікації періодично ламалися. Не тому, що SaaS був недоступний, а тому, що фільтрація і кешування корпоративного резольвера відрізнялися від публічного DNS. Декілька CDN повернули інші відповіді, і додатки поводилися інакше. Команда «оптимізувала» запобігання витокам і створила єдину точку відмови для всього веб-серфінгу.

Виправлення було нуднішим: split DNS для внутрішніх зон і розумні правила виходу для запобігання витоків DNS (блокувати прямі UDP/53 в інтернеті на керованих пристроях там, де це доречно, одночасно дозволяючи політики DoH для публіки). Корпоративний резольвер лишився в ланцюжку лише для доменів, якими він володіє. Користувачі перестали скаржитися, а безпека отримала контроль — без перетворення DNS на вузьке місце.

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

Інша організація зробила нудну річ: написали односторінковий «контракт DNS для VPN». Він визначав: внутрішні простори імен, авторитетні резольвери, поведінку рекурсії, очікувані розміри відповіді та як саме клієнти Linux і Windows повинні маршрутизувати ці запити при підключенні. Ніяких водевілів. Ніяких «повинно бути».

При розгортанні WireGuard вони не просто розсилали конфіги. Вони розіслали тести. Маленький скрипт перевіряв: тунель піднято, маршрут до DNS через wg, прямий dig @dns працює, системний резольвер використовує правильний сервер для corp доменів, і пакетний захоплення показує відсутність витоку для внутрішніх доменів.

Через місяці мережна зміна додала нову внутрішню зону з великими DNS-відповідями. Дехто почав бачити переривчасті збої саме для тієї зони. Завдяки контракту і тестовому набору, черговий швидко відтворив проблему і побачив фрагментацію. MTU був придатний для більшості трафіку, але маргінальний для EDNS важких відповідей.

Вирішення було механічним: підкоригувати MTU і, для внутрішніх рекурсивних резольверів, налаштувати відповіді, щоб уникнути занадто великих UDP-відповідей, де це можливо. «Нудна практика» не була про підкоригування MTU — вона була про те, що вони могли виявити і локалізувати відмову за хвилини. Без героїзму. Без all-hands. Просто дисципліноване, спостережуване життя.

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

Контрольний список A: DNS повного тунелю, який реально працює (Linux + Windows)

Оберіть VPN DNS-сервер, доступний з тунельної підмережі й дозволяє рекурсію з неї.
Додайте IP DNS-сервера до AllowedIPs (принаймні як /32), щоб маршрути були детерміновані.
Linux:
- Якщо використовуєте systemd-resolved — задайте DNS для лінку wg через resolvectl dns wg0 ... і переконайтеся, що його можна використовувати як дефолт.
- Якщо не використовуєте resolved — переконайтеся, що існує resolvconf або керуйте /etc/resolv.conf вручну.
Windows:
- Задайте DNS адаптеру WireGuard у профілі тунелю.
- Переконайтеся, що метрика інтерфейсу віддає перевагу WireGuard, якщо ви хочете, щоб він був дефолтом.
Перевірте через захоплення пакетів, що DNS-запити йдуть у тунель.
Перевірте за допомогою Resolve-DnsName / getent, що додатки бачать правильні результати.

Контрольний список B: Split DNS для корпоративних зон (рекомендовано)

Визначте внутрішні простори імен (corp, internal.corp тощо). Будьте конкретні.
Linux: налаштуйте routing domains у systemd-resolved на wg0:
- resolvectl dns wg0 10.50.0.53
- resolvectl domain wg0 ~corp (і додаткові простори за потреби)
Windows: створіть NRPT правила для кожного простору імен:
- Add-DnsClientNrptRule -Namespace '.corp' -NameServers '10.50.0.53'
Тримайте публічний DNS у локальній мережі або на виділеному публічному резольвері, а не на корпоративному внутрішньому резольвері.
Тест:
- Внутрішні імена розв’язуються через VPN DNS.
- Публічні імена розв’язуються без VPN (якщо ви цього очікуєте).

Контрольний список C: Коли «DNS не працює» — це насправді MTU

Відтворіть проблему з «великою» відповіддю (TXT, DNSSEC або внутрішнє ім’я з багатьма A/AAAA записами).
Захопіть DNS-пакети і шукайте відсутні відповіді або фрагменти.
Зменшіть MTU на wg інтерфейсі (спробуйте 1380) і протестуйте знову.
Якщо зменшення MTU вирішило проблему — залиште менший MTU і задокументуйте причину. Також перевірте upstream PMTU, якщо можете.

Поширені питання

1) Чому WireGuard підключається, але DNS не працює?

Тому що тунель може бути здоровий, а ваша ОС продовжує використовувати старі DNS-сервери або маршрути DNS-запитів поза тунелем. WireGuard сам по собі не «володіє» DNS; він просто переміщує пакети.

2) Чи достатньо `DNS=` у wg-quick?

Іноді. Це залежить від того, чи є у вашій системі інструменти інтеграції резольвера, яких очікує wg-quick. На системах з systemd-resolved явні хуки через resolvectl більш детерміновані.

3) Чому `dig @10.50.0.53` працює, але звичайні запити — ні?

Тому що прямий dig обходить вибір резольвера ОС і можливі маршрутні особливості. Ваш системний резольвер все ще вказує в інше місце або застосовує split DNS правила, які ви не врахували.

4) Чи потрібно додавати IP DNS-сервера до `AllowedIPs`?

Якщо DNS-сервер знаходиться за тунелем — так. Додайте його явно як /32, якщо потрібно. Інакше система може намагатися дістатися до нього через дефолтний шлюз і таймаутитися.

5) Який найчистіший спосіб реалізувати split DNS на Linux?

systemd-resolved routing domains: задайте DNS на wg0 і призначте ~corp домени для нього. Це уникає глобальних змін DNS і зберігає зовнішнє розв’язування локальним.

6) Який найчистіший спосіб реалізувати split DNS на Windows?

NRPT правила для кожного простору імен. Вони примушують використовувати вказаний DNS-сервер для цих доменів незалежно від метрик інтерфейсів чи перепідключень Wi‑Fi.

7) Чому деякі додатки все ще «витікають» DNS, навіть якщо я налаштував VPN DNS?

Деякі додатки використовують DNS-over-HTTPS або власні резольвери і обходять налаштування ОС. Вирішення цього — політика на рівні додатків, а не налаштування WireGuard.

8) Як визначити, чи DNS-запити виходять поза тунель?

Захопіть пакети на обох інтерфейсах. Якщо ви бачите UDP/53 на Wi‑Fi/eth0 замість wg0 — це маршрут/політика. Не гадати; спостерігайте.

9) Чому DNS повільніший через VPN, навіть коли він «працює»?

Затримка, розташування резольвера і поведінка кешування. Корпоративний резольвер далеко від користувача нараховує податкову затримку на кожну веб-сторінку. Split DNS зменшує цей податок.

10) Чи варто запускати локальний кешуючий резольвер на клієнті?

Це може допомогти з продуктивністю, але додає ще один шар, який може кешувати неправильний upstream. Якщо робите це — налаштуйте вибір upstream уважно і протестуйте поведінку split DNS.

Висновок: наступні кроки, які дійсно працюють

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

Доведіть L3-зв’язність першою. Хендшейк і доступність DNS-сервера по IP — ваші базові факти.
Спостерігайте, куди йдуть DNS-пакети. Захоплення пакетів припинить суперечки миттєво.
Зробіть вибір DNS детермінованим. У Linux — надавайте перевагу per-link DNS у systemd-resolved з routing domains для split DNS. У Windows — використовуйте NRPT для split DNS і метрики тільки тоді, коли хочете «дефолт все».
Маршрутуйте DNS-сервер через тунель. Включіть його в AllowedIPs, щоб він випадково не зациклювався через локальний шлюз.
Задокументуйте очікувану поведінку. DNS повного тунелю і split DNS — різні продукти. Оберіть один і запишіть його.

Зробіть це, і DNS перестане бути «таємничо зламаним». Він перетвориться на систему з вхідними даними, виходами і паперовим слідом. Це єдиний тип «магії», яку мають терпіти операційні команди.