Як виявити витік DNS? 4 кроки перевірки DNS проксі

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

Налаштували проксі, відкрили сайт перевірки IP, сторінка показує адресу проксі, і здається, що з мережевим оточенням усе гаразд. А за кілька днів, розбираючись із підозрілою активністю акаунтів, ви виявляєте, що DNS-запити весь час ішли через локальну мережу.

Проблема може бути не в проксі: DNS-запити могли не йти через нього.

Чому перевіряти DNS потрібно навіть із проксі

Проксі та DNS є двома різними етапами: увімкнений проксі не означає, що DNS теж перейнято. Проксі визначає, через який мережевий канал відправляється з'єднання, а DNS відповідає за розпізнавання доменних імен. Це різні мережеві ланки: справний проксі не гарантує, що DNS-запити поводяться так, як очікується.

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

Варто також розмежувати межі: витік DNS не дорівнює розкриттю справжньої публічної IP-адреси. Витікає шлях запитів доменів, через що служба розпізнавання або локальна мережа може побачити, які домени ви шукали. Чи розкрита справжня IP-адреса, визначає окрема перевірка IP. Агентство кібербезпеки Сінгапуру в рекомендаціях із безпеки VPN саме тому вносить тест витоку DNS і тест витоку IP-адреси як дві окремі перевірки: вони перевіряють різні речі (див. настанови CSA з безпеки VPN).

Як зазвичай виникає витік DNS

Найчастіше зустрічаються три джерела, і всі вони пов'язані з налаштуваннями, а не з несправністю проксі. Розгляньмо кожне.

Проксі обробляє лише частину трафіку

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

У браузері ввімкнено окремий захищений DNS

Chrome і Firefox підтримують DNS over HTTPS (DoH): після ввімкнення запити розпізнавання надсилаються зашифрованим з'єднанням HTTPS до вказаної служби, що зменшує можливості локальної мережі безпосередньо спостерігати за запитами. Але шифрування не означає, що запити обов'язково йдуть через проксі, і не гарантує, що обрана служба відповідає очікуванням поточного оточення. Цю функцію Firefox можна вмикати окремо, див. офіційну документацію Mozilla.

Система, браузер і клієнт проксі використовують різні резолвери

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

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

Як перевірити витік DNS: чотири кроки

Сама перевірка нескладна: головне мати очікування до тесту та базу для порівняння після нього. Лише після всіх чотирьох кроків висновок можна вважати обґрунтованим.

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

Крок 2: запустіть тест із увімкненим проксі. Скористайтеся сайтом із перевіркою витоку DNS, наприклад dnsleaktest.com: натисніть розширений тест (Extended test), щоб сторінка показала більше резолверів. Можна також відкрити сторінку перевірки DNS на BrowserLeaks і подивитися, яким організаціям належать резолвери. Запишіть назви резолверів, організації та регіони.

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

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

Як читати результати перевірки

Один і той самий результат: правильне тлумачення дає підказку, неправильне веде до хибного висновку. Що робити з п'ятьма типовими результатами:

Ще одна пастка: Anycast і розподілені вузли приховують справжній вихід.

Чим відрізняються витік DNS, витік WebRTC і відбиток браузера

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

Найлегше сплутати DNS і WebRTC, адже обидва мають у назві слово «витік». Але принципи перевірки та способи реагування в них зовсім різні. Перевірка та налаштування витоку WebRTC розглянуті в окремому матеріалі, тут зупинятися не будемо. До того ж витік IPv6 це ще один пункт того ж сімейства: він шукає, чи обходить проксі IPv6-адреса. Методи описані в посібнику з перевірки витоку IPv6.

Ці чотири пункти відображають різні дані і не замінюють один одного. Розбираючись у проксі-оточенні, радимо спершу перевірити публічну IP-адресу, потім DNS і WebRTC, а в кінці звірити відбиток і конфігурацію оточення. Конкретний набір залежить від вашого сценарію.

Як вписати ці перевірки у роботу з MostMate

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

Перше: конфігурація проксі. Після прив'язки проксі до оточення перевірте стан з'єднання через тест проксі в самому продукті, заодно звіривши тип протоколу (HTTP, HTTPS, SOCKS5, SSH) і дані авторизації. Пам'ятайте, що успішний тест проксі не замінює перевірку витоку DNS: реальний шлях DNS-запитів досі залежить від конфігурації клієнта проксі, браузера та системи.

Далі відкрийте сторінку перевірки DNS в оточенні з прив'язаним проксі: метод той самий, чотири кроки вище, а дивіться, чи відповідають власники резолверів очікуванням.

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

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

Часті запитання

Проксі ввімкнено, а перевірка DNS показує локальний резолвер. Чи означає це, що проксі не працює?

Не обов'язково. Проксі міг перейняти лише вебзапити, а розпізнавання виконується системою чи браузером окремо. По черзі перевірте обробку DNS у клієнті проксі та налаштування DoH браузера, змінюючи по одному пункту за раз.

Чи розкриє витік DNS мою справжню IP-адресу?

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

Чи може статися витік DNS при використанні антидетект-браузера?

Так, може. Антидетект-браузер керує ізоляцією оточення і параметрами відбитка, тоді як поведінка DNS залежить від протоколу проксі та конфігурації системи й браузера. Тому перевірку не варто пропускати.

Перевірка DNS пройшла успішно. Що перевіряти далі?

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

Підсумок

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

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