Приватний DNS проти VPN: що насправді охоплює кожен рівень

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

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

Тож пройдіть це по порядку на пристрої, де ввімкнено і те й інше, і зауважте, що ще може бачити кожен рівень.

Крок перший: пошук залишає застосунок

Ви натискаєте на посилання. Перш ніж щось підключиться, застосунку потрібна адреса для цього імені хоста. В Android потрібний екран — Налаштування, Мережа та інтернет, Приватний DNS. Якщо вибрати Ім’я хоста провайдера приватного DNS, пристрій переходить у суворий режим: він виконує DNS поверх TLS до цього імені хоста на порту 853, і якщо зашифрований обмін не вдається, пошук завершується невдачею, а не тихо відкочується до відкритого тексту на порту 53.

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

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

Крок другий: з’єднання йде іншим маршрутом

Резолвер повертає адресу, і застосунок підключається до неї. На цей крок не впливає те, як було зашифровано пошук. Без тунелю з’єднання виходить із вашої звичайної публічної адреси, і IP призначення разом із рукостисканням TLS зазвичай усе одно роблять ім’я хоста видимим для мережі, із зашифрованим DNS чи без нього.

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

Це розділення і є весь порівняльний аналіз в одному реченні. Шифрування DNS відповідає на питання, хто може прочитати питання. VPN відповідає на питання, куди йде розмова.

Крок третій: усередині тунелю DNS стає питанням політики

Тепер дві функції взаємодіють, і браузер — звичне джерело сюрпризів. Браузер із власним налаштуванням безпечного DNS може надсилати пошуки обраному ним резолверу через HTTPS, замість того щоб питати операційну систему. Налаштування приватного DNS в Android у це рішення не проникає.

У Firefox перемикач міститься в розділі Налаштування, Приватність і безпека, Увімкнути безпечний DNS. У Chrome — у розділі Налаштування, Конфіденційність і безпека, Використовувати безпечний DNS. Обидва можна прив’язати до конкретного провайдера або залишити вимкненими, і коли вони ввімкнені, конфігурація DNS тунелю обходиться для цих пошуків, хоча трафік сторінки далі йде через тунель.

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

Крок четвертий: внутрішні імена — те місце, де все ламається

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

Та сама поломка проявляється навпаки в Android. Суворий приватний DNS із публічним провайдером не розв’яже імена, які знає лише внутрішній резолвер, а в суворого режиму немає запасного шляху. Розділяти DNS телефона між публічним зашифрованим резолвером і корпоративним резолвером — це не налаштування, а питання політики маршрутизації, на яке має відповісти той, хто керує VPN.

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

Що цей прохід велить вам змінити

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

1. Налаштування Android, Мережа та інтернет, Приватний DNS: Автоматично або ім’я хоста провайдера, і яке саме ім’я.
2. Налаштування безпечного DNS браузера: вимкнене або прив’язане до конкретного резолвера.
3. Політика DNS клієнта VPN: чи передає він резолвер і чи виключає роздільний тунель щось, чому ще потрібні імена?
4. Перевірка внутрішнього імені хоста при піднятому тунелі, виконана двічі: один раз із увімкненим DNS браузера, один раз із вимкненим.

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

І тримайте в полі зору обмеження. Жодна з функцій не робить ворожу адресу безпечною, і жодна не прибирає особу, під якою ви ввійшли. Шифрування змінює, хто може прочитати питання; тунель змінює, куди йде з’єднання; ні те ні інше не анонімізує обліковий запис.