Сеть

Предотвращение утечек DNS: защитите свою активность в интернете

Как утечки DNS раскрывают вашу активность в интернете и реальное местоположение, и как направлять DNS-разрешение через прокси для полной приватности.

Документация

Нужна поддерживаемая продуктовая документация?

У этой статьи есть соответствующая страница в центре документации. Используйте docs для каноничного сценария настройки, актуальных флагов и долгосрочной справки.

Введение

Когда вы используете прокси для защиты своей интернет-идентичности, вы ожидаете, что весь трафик будет маршрутизироваться через этот прокси. Однако DNS-запросы часто идут другим путём. Прежде чем ваш браузер сможет подключиться к веб-сайту через прокси, ему нужно разрешить доменное имя в IP-адрес. Если этот DNS-запрос идёт к резолверу вашего интернет-провайдера, а не через прокси, провайдер видит каждый домен, который вы посещаете. Это утечка DNS, и это один из наиболее распространённых способов, которыми конфигурации приватности на основе прокси терпят неудачу.

BotBrowser решает проблему утечек DNS на уровне движка браузера с помощью флага --bot-local-dns, который включает встроенный локальный DNS-резолвер, обеспечивающий контроль над разрешением имён.

Влияние на приватность

Утечки DNS подрывают приватность прокси несколькими способами. DNS-резолвер вашего интернет-провайдера логирует каждый домен, который вы разрешаете, создавая полную запись вашей активности в интернете. Это происходит даже тогда, когда весь HTTP и HTTPS трафик маршрутизируется через прокси. Провайдер видит доменные имена, время ваших запросов и ваш реальный IP-адрес.

Помимо видимости для провайдера, DNS-запросы раскрывают ваше географическое расположение. DNS-резолверы являются региональными. Если вы используете прокси в Германии, но ваши DNS-запросы идут к резолверу в Вирджинии, географическое несоответствие очевидно. Системы отслеживания, которые сопоставляют расположение DNS-резолвера с заявленным IP-расположением, могут выявить это несоответствие.

Утечки DNS также могут происходить по менее очевидным путям. DNS-предвыборка (prefetching), которую браузеры используют для ускорения навигации, может разрешать домены до того, как вы на них нажмёте. WebRTC может инициировать DNS-запросы вне пути прокси. Некоторые конфигурации прокси обрабатывают TCP-трафик, но оставляют UDP-based DNS-запросы незащищёнными.

Контроль DNS на уровне движка BotBrowser закрывает все эти пути одновременно.

Техническая основа

Как работает DNS-разрешение в браузерах

Когда вы переходите на https://example.com, браузер должен разрешить example.com в IP-адрес перед установкой соединения. Процесс разрешения обычно проходит следующим путём:

  1. Браузер проверяет свой внутренний DNS-кеш
  2. Если не закешировано, запрашивает DNS-резолвер операционной системы
  3. Резолвер ОС проверяет свой собственный кеш, затем перенаправляет запрос настроенным DNS-серверам (обычно серверам вашего провайдера)
  4. DNS-сервер отвечает IP-адресом

Когда настроен прокси, идеальное поведение зависит от протокола прокси:

  • SOCKS5H: браузер отправляет имя хоста напрямую прокси, который выполняет DNS-разрешение. Локальный DNS-запрос не происходит.
  • SOCKS5: браузер разрешает DNS локально, затем отправляет разрешённый IP прокси. DNS-запрос утекает.
  • HTTP CONNECT: браузер отправляет имя хоста прокси в запросе CONNECT. DNS-разрешение зависит от реализации.

DNS-предвыборка и спекулятивное разрешение

Современные браузеры агрессивно выполняют предварительную выборку DNS-записей для уменьшения задержки. Когда страница содержит ссылки, браузер может разрешить эти домены до того, как вы нажмёте на них. Эта предвыборка происходит на уровне движка браузера и может не учитывать настройки прокси во всех конфигурациях.

Аналогично, браузеры выполняют спекулятивное DNS-разрешение для доменов, которые появляются в адресной строке по мере ввода. Эти запросы по умолчанию идут через резолвер ОС, создавая пути утечки, которые трудно контролировать только настройками прокси.

Проблема с DNS прокси-провайдера

Даже когда DNS-запросы маршрутизируются через прокси (как в случае SOCKS5H), поведение DNS прокси-провайдера может быть неидеальным:

  • Провайдер может использовать DNS-серверы, не соответствующие географическому региону прокси
  • DNS-ответы могут кешироваться или переписываться провайдером
  • Политики DNS провайдера могут блокировать определённые домены
  • Поддержка DNS-over-HTTPS или DNS-over-TLS варьируется у разных провайдеров
DNS Leak Path vs. Protected Path DNS Leak (without --bot-local-dns): Browser ISP DNS Proxy Destination DNS leak! Protected (with --bot-local-dns): BotBrowser Local DNS Proxy Destination All traffic via proxy No DNS queries reach ISP. All resolution happens locally or through the proxy tunnel.

Распространённые подходы и их ограничения

Использование SOCKS5H вместо SOCKS5

Переключение с socks5:// на socks5h:// указывает браузеру отправлять имена хостов прокси для разрешения вместо локального разрешения. Это хороший первый шаг, но он имеет ограничения:

  • DNS-предвыборка может по-прежнему использовать локальный резолвер для спекулятивных запросов
  • Поведение DNS прокси-провайдера вне вашего контроля
  • Не все протоколы прокси поддерживают удалённое DNS-разрешение
  • Поведение внутреннего DNS-кеширования браузера различается в зависимости от реализации

DNS-конфигурация на уровне системы

Настройка ОС на использование определённых DNS-серверов (таких как 1.1.1.1 Cloudflare или 8.8.8.8 Google) предотвращает просмотр DNS-запросов вашим провайдером, но DNS-сервер всё равно их видит. Эти DNS-серверы часто расположены в других географических регионах, чем ваш прокси, создавая несоответствия расположения. Системный DNS также не решает проблему внутренней DNS-предвыборки браузера.

DNS-over-HTTPS (DoH)

Chromium поддерживает DNS-over-HTTPS, который шифрует DNS-запросы. Это предотвращает чтение DNS-трафика вашим провайдером, но провайдер DoH по-прежнему видит запросы и ваш реальный IP-адрес (поскольку DoH-запросы во многих конфигурациях идут мимо пути прокси). DoH решает вопрос конфиденциальности, но не самого пути утечки.

DNS-защита на уровне VPN

VPN обычно маршрутизирует все DNS-запросы через VPN-туннель. Это эффективно для общего серфинга, но добавляет накладные расходы полного VPN-туннеля. Для пользователей, которым нужен контроль прокси для каждого браузера или контекста, VPN слишком грубый инструмент.

Подход BotBrowser

Флаг --bot-local-dns

Флаг --bot-local-dns (ENT Tier1) BotBrowser включает локальный DNS-резолвер, встроенный в движок браузера:

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns

Этот флаг контролирует поведение DNS на уровне сетевого стека, что означает:

  • Все DNS-запросы обрабатываются локально. Ни один запрос не достигает резолвера вашего провайдера.
  • DNS-предвыборка учитывает конфигурацию прокси. Спекулятивные запросы не утекают.
  • WebRTC и другие протоколы не могут инициировать незащищённые DNS-запросы. Защита покрывает все сетевые пути.
  • Защита невидима для веб-сайтов. Нет наблюдаемых различий в поведении DNS с точки зрения страницы.

Когда использовать --bot-local-dns

Флаг --bot-local-dns наиболее полезен, когда:

  • Ваш прокси-провайдер блокирует или переписывает DNS-запросы
  • Вам нужно согласованное поведение DNS при нескольких запусках
  • Вы хотите предотвратить применение политик DNS на стороне провайдера
  • Вы используете прокси SOCKS5 (не SOCKS5H) и хотите предотвратить утечку через локальное DNS-разрешение

Комбинирование с другими сетевыми защитами

Для комплексной сетевой приватности комбинируйте DNS-защиту с настройками прокси и WebRTC:

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns \
       --bot-webrtc-ice="google"

Эта конфигурация закрывает все три основных пути сетевых утечек: HTTP/HTTPS трафик идёт через прокси, DNS-запросы разрешаются локально, а ICE-кандидаты WebRTC контролируются.

Конфигурация и использование

Базовая настройка CLI

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns

Развёртывание на headless-сервере

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns \
       --headless=new

Интеграция с Playwright

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-local-dns',
      '--bot-webrtc-ice=google',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');

  // Проверка отсутствия утечки DNS
  const ip = await page.evaluate(async () => {
    const res = await fetch('https://httpbin.org/ip');
    return res.json();
  });
  console.log('Detected IP:', ip.origin);

  await browser.close();
})();

Интеграция с Puppeteer

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-local-dns',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Верификация

После запуска BotBrowser с --bot-local-dns:

  1. Перейдите на сайт тестирования DNS-утечек (например, dnsleaktest.com или browserleaks.com/dns)
  2. Запустите расширенный тест, который выполняет множество запросов для выявления всех резолверов
  3. Убедитесь, что в результатах не появляются DNS-серверы, принадлежащие вашему провайдеру
  4. Подтвердите, что все DNS-запросы разрешаются через ожидаемые серверы
  5. Проверьте, что расположение DNS-резолвера соответствует географическому региону вашего прокси

Для автоматической проверки:

const page = await context.newPage();
await page.goto('https://httpbin.org/ip');
const ipResponse = await page.textContent('body');
console.log('HTTP IP:', ipResponse);

// IP из HTTP-запросов должен совпадать с IP прокси
// DNS-запросы не должны раскрывать другое расположение

Лучшие практики

  1. Всегда используйте --bot-local-dns с прокси. Утечки DNS - наиболее распространённый пробел в приватности при настройке прокси. Этот флаг закрывает пробел на уровне движка.

  2. Используйте SOCKS5H для дополнительной защиты. Комбинация socks5h:// с --bot-local-dns обеспечивает два уровня предотвращения утечек DNS.

  3. Комбинируйте с --bot-webrtc-ice. DNS и WebRTC - два наиболее распространённых пути сетевых утечек. Закройте оба для комплексной защиты.

  4. Тестируйте с расширенными тестами DNS-утечек. Быстрые тесты могут не выявить все пути утечек. Расширенные тесты, выполняющие множество запросов с течением времени, более тщательны.

  5. Мониторьте поведение DNS в CI/CD. Если вы запускаете автоматизированные пайплайны, включите проверку DNS-утечек как шаг теста для раннего обнаружения неправильных конфигураций.

  6. Не смешивайте системные DNS-инструменты с BotBrowser. Если вы настраиваете DNS на уровне системы вместе с --bot-local-dns, взаимодействие может дать неожиданные результаты. Позвольте BotBrowser управлять DNS-разрешением.

Часто задаваемые вопросы

Работает ли --bot-local-dns без прокси? Да, флаг включает локальное DNS-разрешение независимо от конфигурации прокси. Однако без прокси ваш реальный IP виден в HTTP-запросах, поэтому одна лишь DNS-приватность даёт ограниченную пользу.

Влияет ли --bot-local-dns на скорость загрузки страниц? Локальный DNS-резолвер добавляет минимальные накладные расходы. В некоторых случаях он может быть быстрее, чем маршрутизация DNS-запросов через прокси-провайдера, у которого медленные или географически удалённые DNS-серверы.

Можно ли использовать --bot-local-dns с HTTP-прокси? Да. Флаг работает со всеми протоколами прокси: SOCKS5, SOCKS5H, HTTP и HTTPS.

Какие DNS-серверы использует --bot-local-dns? Локальный резолвер обрабатывает DNS-разрешение внутри движка браузера, избегая DNS-запросов на уровне ОС. Конкретная стратегия разрешения управляется внутренне для обеспечения согласованности.

Предотвращает ли --bot-local-dns DNS-предвыборку? Да. Всё DNS-разрешение, включая предвыборку и спекулятивное разрешение, проходит через локальный резолвер. Ни один DNS-запрос не утекает через пути предвыборки.

Можно ли комбинировать --bot-local-dns с DoH на уровне браузера? Не рекомендуется. Флаг --bot-local-dns обеспечивает комплексный контроль DNS. Добавление DoH поверх может создать конфликтующие пути разрешения.

Нужен ли --bot-local-dns при SOCKS5H? SOCKS5H уже маршрутизирует разрешение имён хостов через прокси. Однако --bot-local-dns обеспечивает дополнительную защиту от DNS-предвыборки и других спекулятивных путей разрешения, которые SOCKS5H может не покрывать.

Итоги

Утечки DNS - это распространённый и серьёзный пробел в приватности, который возникает даже когда весь HTTP-трафик маршрутизируется через прокси. Флаг --bot-local-dns BotBrowser закрывает этот пробел на уровне движка браузера, обеспечивая, что ни один DNS-запрос не достигает вашего провайдера или любого резолвера вне вашего контроля. В сочетании с конфигурацией прокси и защитой WebRTC он обеспечивает комплексную сетевую приватность.

Для полной сетевой защиты сочетайте предотвращение утечек DNS с Конфигурацией прокси и Предотвращением утечек WebRTC. Для управления множеством идентичностей с полной сетевой изоляцией смотрите Изоляция мультиаккаунтного браузера.

#Dns#Leak-Prevention#прокси#Privacy#Network

Переведите BotBrowser из исследований в продакшн

Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.