Если сайт показывает IP вашего прокси, это ещё не означает, что все сетевые запросы идут через него. Страница может загружаться через один выход, DNS — обращаться к домашней сети, а WebRTC — устанавливать соединение по третьему маршруту.
Привет! Сегодня разберём, какую информацию раскрывает DNS, почему важен DNS именно провайдера выхода, как отдельно может утекать резолвинг WebRTC и что нужно настроить в BlankTrail Proxy, чтобы эти маршруты работали вместе. Отдельно покажем, зачем BlankTrail использует собственную базу провайдерских DNS-серверов, обслуживающих только клиентов своих сетей.
1. DNS — отдельная часть сетевой картины
DNS переводит доменное имя в IP-адрес. Программа задаёт вопрос рекурсивному резолверу, а тот возвращает ответ из кеша или получает его у других DNS-серверов. Авторитетный сервер хранит записи конкретного домена. Для домашнего подключения резолвер обычно назначает интернет-провайдер или администратор сети, но пользователь может выбрать другой. Это описано, например, в документации Cloudflare.
У загрузки страницы и у получения её адреса разные задачи. Поэтому настройка HTTP- или SOCKS-прокси сама по себе не описывает маршрут каждого DNS-запроса на компьютере.
Здесь полезно различать, кто именно наблюдает запрос. Рекурсивный резолвер видит адрес, с которого к нему подключились. Авторитетный сервер домена обычно видит IP рекурсивного резолвера; дополнительные сведения о клиенте могут передаваться через ECS (EDNS0 Client Subnet - это расширение протокола DNS, которое позволяет DNS-серверу передавать часть IP-адреса пользователя). Если же клиент сам обращается к авторитетному серверу напрямую, тот видит адрес этого подключения. Эти различия разобраны в RFC 9076.
Сайт не получает список ваших DNS-серверов в обычном HTTP-заголовке. Для диагностики он может попросить браузер обратиться к уникальному поддомену в контролируемой зоне и сопоставить DNS-наблюдение с конкретной сессией. В таком тесте видно, откуда пришёл DNS-запрос, и был ли в нём ECS. Именно поэтому DNS может стать дополнительным сигналом при анализе соединения.
2. Почему DNS провайдера выхода выглядит естественнее
При обычном домашнем или мобильном подключении IP и DNS часто относятся к одной сетевой среде: адрес выдал провайдер, он же предоставил резолвер. Исторически выбор сети определял системный DNS, хотя сегодня приложения могут выбирать собственные сервисы. Этот фон описан в RFC 9076 о выборе резолвера.
Представим, что HTTP-запрос приходит с резидентского IP одного провайдера, а DNS-проверка показывает резолвер домашнего провайдера пользователя в другой стране. Для системы, которая сопоставляет эти признаки, возникает вопрос: почему два запроса одной сессии относятся к разным подключениям?
Отсюда практический вывод: для резидентского или мобильного выхода DNS его провайдера часто создаёт более согласованную картину. Он соответствует тому подключению, с которого сайт получает основной трафик. Это аргумент о согласованности сигналов, а не универсальное правило любой антифрод-системы.
DNS для абонентов и открытые списки — разные вещи
Провайдерский рекурсор может обслуживать только клиентов своей сети: принимать запросы с их подключений и отказывать посторонним. Открытый резолвер, напротив, отвечает любому доступному клиенту. Для нашей задачи существенно именно это различие: DNS абонентской сети соответствует обычному способу получения адресов на таком подключении.
Общедоступный список работающих DNS не воспроизводит DNS провайдера выхода. Даже если сервер из списка расположен в нужной стране или его IP зарегистрирован на интернет-провайдера, он может быть открытым для всех. Сам факт ответа не означает, что это штатный абонентский рекурсор выбранной сети. Для антифрода, который сопоставляет IP и DNS-инфраструктуру, такая замена не даёт того преимущества в согласованности, ради которого нужен провайдерский DNS.
Более того, случайный открытый резолвер чужой сети может давать менее естественную картину, чем Google Public DNS. Google DNS используют обычные пользователи, поэтому у такого выбора есть понятное бытовое объяснение. Массовое использование Google Public DNS видно, например, в измерениях APNIC Labs за май 2026 года: xуть менее 10% пользователей интернета в мире и более 20% (каждый пятый) интернет-пользователей имеют настроенный DNS от Google в качестве вторичного или резервного бэкап-резолвера. А обращение с резидентского IP к малоизвестному открытому DNS другого оператора не становится естественным только потому, что оба адреса относятся к одной стране. Это вывод о согласованности признаков, конкретная антифрод-система может учитывать их по-разному.
Публичный DNS тоже используют обычные люди. Провайдер может передавать резолвинг стороннему оператору, браузер — включать защищённый DNS, а корпоративная сеть — использовать общую инфраструктуру. Поэтому Google DNS или Cloudflare сами по себе не доказывают автоматизацию. Но Согласно всё тому же исследованию APNIC Labs за май 2026 года доля Google DNS стабильно удерживает в районе 6% – 18% от общего мирового объема трафика в зависимости от региона, оставаясь крупнейшим в мире альтернативным публичным DNS-провайдером. Напрямую с ней конкурирует только Cloudflare. И это всё ещё очень мало относительно мало от общей массы использующий DNS своего провайдера, а в глазах антифрода именно свой провайдер DNS даст определённый траст, т.к. у реальных пользователей это 80%+ от массы, а боты наоборот почти не бывают с таким DNS.
Для серверного прокси ситуация может быть другой: подходящего абонентского DNS у такого выхода нет. Здесь разумнее выбрать доступный и согласованный способ резолвинга, чем искусственно добиваться названия какого-либо домашнего провайдера в тесте.
3. Как через DNS раскрывается IP или подсеть
Прямое обращение к резолверу
Если DNS-запрос ушёл напрямую из домашнего подключения, резолвер увидит его публичный IP. За домашним роутером или CGNAT это будет внешний адрес соответствующего выхода, а не обязательно частный адрес компьютера. При этом сайт, который получает HTTP через прокси, не узнаёт полный домашний IP автоматически: для этого у него должен быть доступ к соответствующему наблюдению или другому каналу утечки, но серьёзные сайты с антифродом это измеряют и проверяют.
ECS: подсеть внутри DNS-запроса
EDNS Client Subnet, или ECS, — дополнительное поле DNS, которое передаёт информацию о сети клиента. Оно помогает выбирать подходящий узел CDN. Но вместе с этим часть адреса может попасть к авторитетному серверу домена. В RFC 7871 рекомендуется сокращать IPv4-адрес до 24 бит, а IPv6 — до 56 бит для защиты приватности.
Например, для условного домашнего IP 198.51.100.42 ECS может содержать 198.51.100.0/24. Такая запись описывает диапазон из 256 адресов, а не один конкретный IP. Она всё равно сообщает о сети клиента и может помочь связать наблюдения из разных сессий. Длина префикса зависит от реализации и настроек; при передаче полного префикса раскрывается полный адрес.
Google Public DNS поддерживает ECS и определяет поддержку этой функции у авторитетных серверов. Поэтому ECS нельзя считать обязательным полем каждого запроса через Google: поведение зависит от зоны и сервера. См. рекомендации Google по ECS. Cloudflare 1.1.1.1, напротив, не отправляет ECS для обычных доменов; в документации отдельно оговорено исключение для диагностического домена Akamai.
Значит, надпись «публичный DNS» ещё ничего не говорит о наличии домашней подсети в запросе. Нужно проверять фактически полученный ECS. И наоборот: даже DNS, отправленный через правильный туннель, может нести чужую подсеть, если клиент добавил её заранее и она сохранилась при пересылке.
Несколько маршрутов и запасной DNS
Ещё один источник проблем - сочетание нескольких настроек. Браузер использует свой DoH, системная служба — DNS роутера, вспомогательный процесс - отдельный резолвер. При ошибке основной путь может смениться запасным. Отдельно нужно учитывать IPv6: контроль только IPv4 не описывает поведение второго стека.
Поэтому отсутствие ECS в одном запросе и знакомое имя резолвера в одном тесте не подтверждают, что все обращения приложения закрыты.
4. WebRTC: сначала резолвинг, потом соединение
WebRTC нужен для связи браузеров, передачи аудио, видео и данных. При подготовке соединения браузер собирает ICE-кандидаты — возможные адреса и способы связи. Для этого могут использоваться STUN- и TURN-серверы. Механизм описан в руководстве WebRTC по peer connections.
Здесь есть два самостоятельных этапа, которые нужно проверять отдельно.
Этап 1. Получить IP STUN- или TURN-сервера
Если сервер задан доменным именем, браузеру сначала нужен его IP. Это отдельный вызов резолвинга внутри WebRTC, а не загрузка страницы по HTTP. В Chromium P2P-компонент создаёт DNS-запрос через HostResolver — это видно в исходном коде P2PSocketManager.
Отдельный вызов не означает, что WebRTC всегда обходит браузерный DoH: компоненты могут пользоваться общей службой резолвинга. Но конкретный путь зависит от движка, его версии и настроек. Если обращение попадает в системный DNS вне защищённого маршрута, утечка возникает ещё до отправки STUN-пакета. Если сервер задан IP-адресом, этот шаг для его адреса не требуется, кешированный ответ тоже может скрыть DNS-обращение в повторном тесте.
Для проверки можно использовать уникальное имя STUN-сервера в контролируемой DNS-зоне. По нему видно, каким маршрутом разрешается именно имя для WebRTC. Результат обычного DNS-теста страницы не заменяет такую проверку.
Этап 2. Отправить STUN-запрос
После получения адреса начинается сетевой обмен. STUN-сервер видит источник пришедшего пакета и возвращает клиенту наблюдаемый адрес и порт. Это работа STUN, а не DNS; она описана в RFC 8489.
Если пакет ушёл напрямую, сервер может увидеть полный публичный IP домашнего или мобильного подключения. Настройка прокси для веб-запросов не гарантирует маршрут WebRTC. Например, в Chromium SOCKS5 обслуживает TCP-запросы URL и не используется для пересылки UDP - см. документацию прокси Chromium. Риск обхода обычного прокси STUN-проверками отдельно описан в RFC 8828.
Возможны оба варианта: имя STUN-сервера разрешилось через правильный DNS, но пакет ушёл напрямую, либо STUN прошёл через туннель, а предшествующий DNS-запрос - через домашний резолвер. Исправление одного этапа не исправляет второй автоматически.
Подмена адресов WebRTC на уровне JavaScript также не меняет источник уже отправленного пакета. Серверное наблюдение остаётся самостоятельным. Аналогично mDNS-имена для локальных ICE-кандидатов предназначены для сокрытия локальных адресов в передаваемых кандидатах, из этого не следует защита внешнего маршрута. Идея описана в проекте документа IETF о mDNS и ICE.
5. Почему одного DoH недостаточно
DNS-over-HTTPS шифрует запрос до выбранного DoH-сервера. Но шифрование не выбирает выход вместо вас. Если подключение к внешнему DoH идёт напрямую, этот сервис видит адрес прямого подключения. Если запрос передаёт ECS, наличие HTTPS само по себе его не удаляет.
Нужно также проверить поведение при ошибке. Например, стандартная защита DoH в Firefox допускает возврат к обычным резолверам. Максимальная защита показывает предупреждение при недоступности защищённого DNS, исключения для доменов могут разрешать системный DNS. Это описано в настройках уровней защиты Firefox.
Для контролируемого маршрута важны три условия: выбранный сервер, правильный путь до него и отсутствие незапланированного возврата к домашнему DNS. Браузерная настройка DoH распространяется на обслуживаемые ею запросы и не перенаправляет весь трафик компьютера или все соединения WebRTC.
6. Как это решает BlankTrail Proxy
В BlankTrail задача разделена на две части: выбрать правильный способ резолвинга и доставить до него запросы приложения. Для WebRTC к этому добавляется контроль самого сетевого обмена.
vDNS: собственная база абонентских DNS провайдеров
BlankTrail использует собственную базу провайдерских DNS-серверов, которые обслуживают только клиентов соответствующих сетей. Наша база охватывает более 4 000 провайдеров и более 10 000 DNS-серверов. vDNS определяет провайдера и географию выхода и подбирает подходящий доступный резолвер из этой базы.
Именно доступ к абонентской DNS-инфраструктуре через соответствующий выход - важное преимущество такого подхода. Общедоступные списки открытых DNS содержат серверы, отвечающие всем; они не дают эквивалентной связи между выходом и штатным резолвером его провайдера. Количество адресов в таком списке само по себе не улучшает согласованность сетевой картины.
Просто поставить адрес абонентского DNS в настройки компьютера недостаточно. Из чужой сети такой сервер может отказать в рекурсии или не ответить. Запрос должен прийти к нему через выход, относящийся к обслуживаемой сети. Тогда сайт получает основной трафик с IP прокси, а DNS-наблюдение соответствует инфраструктуре того же подключения.
Если подходящий провайдерский DNS недоступен, возможны другие способы: публичный резолвер с ECS подсети выхода, самостоятельный резолвинг через выход или передача имени вышестоящему прокси. Выбор зависит от типа выхода и нужной DNS-политики. При самостоятельном резолвинге запросы к авторитетным серверам приходят с IP выхода, это согласует источник, но не воспроизводит использование обычного провайдерского резолвера.
В BlankTrail vDNS включён по умолчанию. В настройках порта можно выбрать режим его работы: on_leak применяет vDNS после обнаружения DNS-утечки при предварительной проверке, а forced использует его постоянно. При использовании ECS передаваемая подсеть будет соответствовать выбранному выходу. Активация строгой политики при ошибке резолвинга предотвращает продолжение соединения по непредусмотренному пути, по умолчанию включен режим auto, и в этом режиме предпочтение будет отдаваться провайдерским DNS серверам, а если под выход нет подходящего, то публичные DNS сервера Google, Cloudflare, Quad9, но если не работают даже публичные или фильтруют доступ до нужного сайта то далее по цепочке пробуется резолвинг через сам выход или делегирование на сторону прокси, чтобы он попытался провести это на своей стороне.
Собственный DoH: передать запросы браузера в BlankTrail
Для самостоятельных DNS-запросов браузера в BlankTrail есть DoH-сервер на порту продукта. Его адрес можно указать в настройках защищённого DNS. Дальше запрос обрабатывается через выход и по DNS-политике соответствующего порта.
Входящий ECS клиента удаляется, а дальнейшее использование подсети определяется настройками порта. Это закрывает ситуацию, когда запрос пришёл в правильный туннель, но внутри него сохранилась домашняя подсеть.
Для независимых профилей можно назначать DoH разных портов со своими выходами. В браузере нужен строгий режим без автоматического возврата к системному DNS. При этом отдельно проверяется, попадает ли WebRTC-резолвинг конкретного браузера в тот же путь.
TUN: охватить системный DNS и трафик вне прокси
Если приложение отправляет часть обращений через системную службу или не умеет правильно применять прокси, используется TUN-перехват. В BlankTrail он реализован и на Windows, и на macOS, включая перехват отдельных приложений. На Windows перехват обслуживает установленная системная служба; на macOS — системный демон под управлением launchd, использующий штатный туннельный интерфейс utun. Можно выбрать всю систему или отдельные приложения, область перехвата задаётся для порта. Подробности — в документации о перехвате.
На macOS при выборе приложения учитывается его пакет .app, в том числе вложенные процессы-помощники. Для браузеров это особенно важно: сетевые соединения может открывать отдельный помощник внутри пакета браузера. Правило перехвата сопоставляется с приложением, а не только с исполняемым файлом его главного процесса; при выборе маршрута также учитываются правила родительских процессов.
Для обычных DNS-запросов на обеих платформах предусмотрена обработка системного резолвинга. На macOS BlankTrail настраивает системные резолверы средствами сетевой конфигурации ОС, их использует общая служба mDNSResponder. Поэтому выбор браузера в списке перехватываемых приложений сам по себе не означает, что все его DNS-запросы будут распознаны как трафик процесса браузера.
В режиме отдельных приложений отдельно включите захват системного DNS и проверьте обслуживающий его порт. Если приложения используют разные порты и выходы, назначьте этот порт явно. Такая настройка затрагивает общий системный резолвер: разные программы могут направлять свои соединения через разные порты, но общий системный DNS нельзя автоматически считать отдельным DNS-контекстом каждого браузерного профиля.
Такой перехват позволяет охватить и DNS-запросы WebRTC, если они уходят через системный резолвер, и его отдельные сетевые соединения. Для STUN поверх UDP выход должен поддерживать UDP — например, через подходящий туннель или SOCKS5 UDP relay. Обычного HTTP-прокси для этого недостаточно.
Если защищённый выход не поддерживает нужный обмен, правильный результат — отказ этого обмена, а не прямой выход из домашней сети. Поэтому возможность WebRTC и отсутствие утечки оцениваются отдельно. Встроенная проверка обхода порта позволяет наблюдать такой трафик или блокировать его, vDNS, DoH и TUN решают разные части общей задачи.
7. Как читать результат: примеры из интерфейса аудита
Наш детектор audit.blanktrail.com показывает браузерный отчёт в HTML и отдаёт данные сессии в JSON. Для HTTP-клиентов есть отдельный JSON-ответ /client. В браузерном отчёте DNS-наблюдения, адреса WebRTC, сообщённые браузером, и серверные наблюдения STUN показаны отдельно.
Ниже — три учебных сценария, отрисованных функциями настоящей страницы аудита и сохранённых в статическом HTML. IP-адреса, страны, домены, число запросов и вердикты заданы для объяснения механизма. Это не замеры «до и после» включения BlankTrail. Четвёртый пример — обезличенный ответ реального HTTP-клиента: его происхождение указано отдельно.
Во всех трёх сценариях ожидаемый выход — 203.0.113.10, его подсеть — 203.0.113.0/24. Условный домашний адрес — 198.51.100.42, домашняя подсеть — 198.51.100.0/24. Резолвер выхода обозначен как 192.0.2.53, домашний — как 192.0.2.54. Адреса взяты из диапазонов для примеров и не описывают реальные подключения.
Пример 1. STUN идёт через выход, но DNS WebRTC раскрывает другую подсеть
В DNS-таблице строка с p1 относится к обычной пробе страницы: резолвер и ECS соответствуют выходу. Строка с rtc1 относится к разрешению имени для WebRTC: в ней другой резолвер и домашняя подсеть. В текущем скрипте есть четыре такие пробы — rtc1–rtc4, для имён STUN и TURN с разными транспортами. Для наглядности в примере оставлены только две DNS-строки.
Предупреждение ecs_foreign указывает на подсеть, которой не принадлежит основной выход. mixed_ecs показывает, что в одной сессии встретились разные ECS. При этом таблица WebRTC содержит 203.0.113.10, а сервер STUN наблюдает 203.0.113.10:54000. Значит, в этом сценарии сам STUN-обмен согласован с выходом, а проблема возникла при предшествующем резолвинге.
В реальной проверке нужно разбирать сами строки: разные ECS могут появиться и при смене выхода. Имя пробы помогает понять, какой запрос относится к WebRTC; по одному коду предупреждения установить причину нельзя.
Пример 2. DNS согласован, а STUN раскрывает домашний IP
Теперь обе DNS-пробы идут через резолвер выхода и передают его подсеть. Но браузер сообщает 198.51.100.42, и сервер STUN видит пакет от 198.51.100.42:54000. В учебном вердикте задано предупреждение webrtc_foreign.
Здесь исправлять только DNS бессмысленно: адрес сервера получен через нужный путь, а последующее соединение ушло напрямую. Серверное наблюдение подтверждает источник пакета независимо от таблицы, которую заполнил JavaScript браузера. Для такого сценария нужен контроль маршрута WebRTC — например, TUN с подходящим выходом и поддержкой UDP, либо блокировка неподдерживаемого обмена.
Пример 3. Все показанные каналы согласованы с выходом
В третьем сценарии обычный DNS и DNS WebRTC используют резолвер выхода, ECS описывает его подсеть, а браузер и сервер STUN показывают адрес выхода. Для примера задано подтверждение провайдерского DNS — dns_resolver_native; оно иллюстрирует соответствующую строку интерфейса, а не проверку условного резолвера в реальной базе.
Такая картина — ожидаемый результат при корректно настроенных vDNS, DoH и TUN в описанном сценарии. Но зелёный итог относится к полученным наблюдениям конкретной сессии. Он не подтверждает поведение каждого приложения, всех запасных маршрутов и будущих соединений. Если WebRTC заблокирован, отсутствие STUN-пакетов также нельзя выдавать за подтверждение того, что они прошли через выход.
Пример 4. JSON HTTP-клиента после DNS-пробы
У /client другой способ запуска. Первый ответ содержит поле dns_probe_url. Нужно обратиться по этому адресу тем же HTTP-клиентом через тот же прокси: уникальное имя запускает DNS-пробу, и ответ по нему содержит блок dns. Ниже показан настоящий ответ такого запроса. IP клиента, его подсеть, PTR и имя пробы заменены; структура, публичный резолвер и остальные значения сохранены.
Поле dns.resolvers описывает наблюдавшиеся резолверы, а dns.client_subnets — переданные клиентские подсети. В этом ответе есть публичный резолвер Google и ECS. Значение resolver_is_egress: false означает, что адрес наблюдавшегося резолвера не совпал с адресом HTTP-клиента; это само по себе не доказывает утечку, поскольку резолвер обычно является отдельным сервером.
Пустой массив findings в этом ответе не заменяет анализ DNS и не подтверждает отсутствие утечек WebRTC. Обычный HTTP-клиент не запускает браузерные ICE-пробы. Аналогично http3.used: false говорит о неиспользованном HTTP/3 в этой проверке, а не об утечке DNS.
8. Как повторить проверку самостоятельно
Проверку стоит проводить на стабильном выходе, чтобы ротация IP не смешивалась с утечками. Сначала зафиксируйте браузер и его версию, тип прокси, ожидаемый выход, режим vDNS, настройки DoH и область TUN.
- Откройте браузерный детектор в проверяемом профиле через нужный выход. Выберите русский язык при необходимости и дождитесь статуса «проверка завершена».
- Сверьте измеренный выход. Он должен соответствовать выбранному подключению. Отдельно учитывайте IPv4 и IPv6; несовпадение адресов при ротации требует повторного теста на стабильном выходе.
- Разберите DNS-таблицу. Сопоставьте обычные имена проб и имена с
rtc1–rtc4. Посмотрите резолверы, операторов и фактический ECS. Если строка не появилась, это отсутствие наблюдения, а не подтверждение защищённого маршрута. - Сравните WebRTC и STUN. Отдельно прочитайте таблицу сведений браузера и таблицу серверных наблюдений. Сверьте источник STUN-пакетов с измеренным выходом. Одного адреса, показанного JavaScript, недостаточно.
- Измените настройки и запустите новую проверку. После включения vDNS, назначения DoH или настройки TUN используйте кнопку «Выполнить проверку повторно» и снова дождитесь завершения. Новая сессия использует новые диагностические имена. Сохраните скриншоты и JSON, чтобы сравнить фактические данные.
- Проверьте поведение при отказе. При недоступности выбранного DNS или туннеля не должен включаться прямой запасной маршрут. Заблокированный обмен и обмен через нужный выход — разные результаты.
Идентификатор браузерной сессии виден в журнале страницы в строке сессия …. Полный JSON доступен по адресу https://audit.blanktrail.com/api/session/<ID>: замените <ID> идентификатором своей проверки. В нём можно отдельно изучить observations, resolvers, client_subnets, webrtc, stun и verdict. Статические HTML-примеры выше подготовлены из интерфейса аудита; отдельную кнопку экспорта такого HTML для повторения теста искать не нужно.
Повторение для HTTP-клиента
Откройте /client именно проверяемым клиентом. Например, для curl через SOCKS5 выполните команду, заменив логин, пароль и порт своими значениями:
curl --silent --show-error --proxy socks5h://USER:PASS@127.0.0.1:20134 https://audit.blanktrail.com/clientВ Windows PowerShell используйте curl.exe, чтобы явно вызвать curl. В обозначении socks5h:// буква h означает передачу имени на разрешение прокси — см. документацию curl. Это настройка curl; она не управляет DNS или WebRTC отдельного браузера.
Из первого JSON скопируйте точное значение dns_probe_url и выполните второй запрос с теми же параметрами. В следующей команде замените весь текст в кавычках полученным URL:
curl --silent --show-error --proxy socks5h://USER:PASS@127.0.0.1:20134 "DNS_PROBE_URL_ИЗ_ПЕРВОГО_ОТВЕТА"Сохраните второй JSON и разберите его блок dns. Если проверяете программный клиент, повторите оба обращения средствами этого клиента: результат curl описывает путь curl. Для WebRTC вернитесь к браузерному детектору.
9. Итог
Согласованная сессия начинается с контроля всех её сетевых маршрутов. Основной IP, DNS страницы, DNS WebRTC, передаваемый ECS и источник STUN-пакетов должны соответствовать выбранному подключению. Проверка только IP страницы оставляет остальные каналы без ответа.
Для резидентского или мобильного выхода особенно важен штатный DNS его провайдера. Собственная база BlankTrail содержит абонентские резолверы, обслуживающие только клиентов соответствующих сетей. Доступ к ним через подходящий выход позволяет использовать ту DNS-инфраструктуру, которой пользуются абоненты этого провайдера. Случайный открытый сервер из общедоступного списка такой связи с подключением не создаёт, даже если находится в той же стране.
В BlankTrail эти задачи решаются совместной настройкой: vDNS выбирает способ резолвинга и использует базу провайдерских DNS, собственный DoH сервер передаёт ему запросы браузера, а TUN охватывает системный DNS и отдельные соединения приложения. Для WebRTC отдельно контролируются разрешение имени сервера и последующий обмен с ним. Если выход не поддерживает нужный обмен, он должен блокироваться без перехода на прямой маршрут.
Проверять результат нужно на фактических наблюдениях: какой резолвер получил запрос, какую подсеть он передал и с какого адреса пришёл STUN-пакет. Откройте детектор BlankTrail до изменения настроек и после него, дождитесь завершения каждой проверки и сравните отчёты. Так можно увидеть, какие маршруты удалось согласовать и где ещё требуется настройка.
