Чому мітка країни в DNS не доводить витік VPN

Адреси розв’язувачів, що виглядають іноземними, постійно з’являються в результатах DNS-тестів, і висновок, до якого приходять люди, завжди той самий: запити, мабуть, вирвалися з тунелю. Іноді так і було. Частіше звіт описує, який рекурсивний сервіс відповів і де, на думку бази даних, розташована ця адреса, а це твердження про інфраструктуру, не про ваші пакети. Щоб відокремити спостереження від висновку, потрібні три факти: хто відповів, як подорожувало ім’я і яку політику ви насправді налаштували.

Прочитайте, що тест насправді спостерігав

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

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

Anycast і пересилання пояснюють більшість несподіванок

Великі публічні розв’язувачі анонсують ту саму адресу з багатьох місць, і мережа спрямовує кожен запит туди, де ближче з погляду маршрутизації. Потім база геолокації прив’язує цю адресу до одного місця, яке може бути корпоративною адресою реєстрації на іншому континенті або центром обробки даних, що не є відповідачем. RFC 4786 описує операційну практику anycast-сервісів і складність прив’язки такої адреси до одного фізичного місця. Карта — це спрощення рішення про маршрутизацію, і вона спрощує в бік, що дає тривожні результати.

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

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

Хто отримав ім’я і яким маршрутом

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

resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net

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

Порівняйте з політикою, яку ви обрали

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

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

Тримайте тести вузькими й безпечними

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

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