VPN DNS проти DoH у браузері: що тест на витік не може сказати

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

Сторінка тесту на витік каже, що ваш DNS у порядку, значок у браузері каже, що все безпечно, а внутрішня вікі досі не завантажується. Усі три можуть бути правдою одночасно, бо адреса резолвера — це не те саме, що політика, яка його обрала, чи шлях, яким пройшов запит. Те, що люди називають витоком DNS, насправді одне питання: який резолвер отримав ім’я і чи цей вибір був навмисним? Щоб це розібрати, потрібні три перевірки, і лише остання передбачає зміну налаштування.

Міф перший: значок називає ваш резолвер

Тест на витік розв’язує пробне ім’я і повідомляє адресу, яка відповіла. Він не повідомляє політику, що обрала цей резолвер, а коли запит загорнуто в DNS over HTTPS, проміжний пристрій на шляху взагалі не бачить імені. Дві дуже різні машини дають той самий заспокійливий значок: одна, де VPN проштовхнув 10.8.0.1 і браузер його використовує, і друга, де браузер зігнорував системний список і надіслав ім’я своєму зашифрованому постачальнику через тунель.

Різниця важлива тієї миті, коли приватне ім’я не розв’язується. У першому налаштуванні резолвер VPN відповідає за корпоративну зону; у другому браузер його взагалі не питав, тож коротке ім’я хоста не розв’язується, і збій виглядає як зламаний VPN. Перевірка — це не ще один тест на витік, це пошук за ім’ям, яке знає лише один резолвер.

Міф другий: браузер виходить із тунелю

DNS обирає адресу, маршрутизація несе з’єднання, і це два окремі шари. Запит, надісланий публічному постачальнику DoH, усе ще є TCP порт 443 до маршрутизованої адреси. Якщо ваша таблиця маршрутів надсилає маршрут за замовчуванням у тунель, цей запит теж іде через тунель. Бренд резолвера не визначає шлях.

Що змінює DoH браузера — це одержувач імен. Це справжнє рішення про приватність і справжнє рішення про політику, але не обхід маршрутизації. Якщо ваша вимога — щоб імена залишалися в оператора VPN, зашифрований запит до когось іншого не виконує цієї вимоги, хоча й далі використовує тунель для фактичного з’єднання.

Міф третій: кожен VPN перекриває кожен браузер

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

Водночас більшість клієнтів VPN встановлюють системний резолвер, коли з’єднання піднімається, і відновлюють попередній, коли воно падає. Браузер, який тримає власний зашифрований резолвер, цього відновлення взагалі не помічає. Ось чому той самий профіль поводиться по-різному на двох ноутбуках і чому resolv.conf виглядає правильно, поки браузер усе ще питає когось іншого.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Запустіть їх, поки з’єднані, занотуйте домени, які заявляє кожен резолвер, і порівняйте з тим, що браузер повідомляє про власний режим. Документація Mozilla про DoH — це розумний опис того, як мають працювати типова та резервна поведінка браузера.

Рішення має три входи, а не один

Приватні імена, довіра до оператора й доступність визначають правильне впорядкування. Імена, які знає лише резолвер VPN, змушують до розділеного DNS: приватний суфікс іде до проштовхнутого резолвера, усе інше йде за політикою, яку ви обрали для публічних імен. Довіра до оператора визначає, чи публічні імена теж мають іти до того резолвера, чи до окремого сервісу. Доступність визначає, чи обраний вами зашифрований резолвер узагалі придатний у цій мережі.

ConditionWhat it forces
Internal names must resolveSplit DNS: private suffixes to the VPN resolver, the rest to your chosen default
Queries must stay with one operatorPin both the system resolver and the browser mode, and disable fallback
Resolver only reachable through the tunnelKeep the pushed resolver; do not point DoH at an endpoint your routes exclude

Жоден із цих рядків не є універсальною рекомендацією. Резолвер, яким керує VPN, зосереджує спостереження в того оператора; окремий сервіс додає ще одного одержувача запитаних імен. Жодне впорядкування нічого не доводить про зберігання, якщо ви не прочитаєте політику.

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

Перевірте політику, яку, як ви думаєте, ви налаштували

Перевіряйте за ім’ям, а не за значком. Розв’яжіть публічне і приватне ім’я через системний резолвер, потім повторіть усередині браузера з його власним налаштуванням безпечного DNS у режимі, який ви збираєтеся використовувати. Якщо приватне ім’я не розв’язується лише в браузері, ви знайшли невідповідність одержувача, не торкнувшись жодного налаштування VPN.

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

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

Схожі статті