Утечки DNS, открытые порты и TLS-отпечатки

Инструмент обхода блокировок заворачивает ваш HTTP-трафик в зашифрованный туннель, и именно за этой частью все следят. Но прежде чем подключиться к сайту, есть более ранний шаг — превращение имени в адрес, — и он часто происходит вне туннеля. Так же легко забыть, какие двери ваша собственная машина держит открытыми в интернет и не болтает ли лишнего само зашифрованное рукопожатие. Сайт проверяет все три: порты — на странице IP, DNS и TLS — на отдельных страницах лаборатории отпечатков. Две последние зависят от отдельного развертывания, так что на некоторых установках вместо результата стоит «не настроено»; механика ниже в любом случае подскажет, на что смотреть.

Как происходит утечка DNS

Чтобы добраться до example.com, браузер сначала спрашивает системный резолвер, какому IP соответствует это имя. При включенном прокси на этот вопрос должен отвечать резолвер на дальнем конце туннеля. Утечка означает, что этого не произошло — запрос ушел напрямую в DNS вашего местного провайдера.

Сломаться это может по-разному. Самый частый случай: инструмент перехватывает TCP-соединения, а система по привычке продолжает слать UDP-запросы на порт 53 провайдеру. Windows добавляет свою особенность — параллельное разрешение: опрашиваются сразу все сетевые интерфейсы, и побеждает первый ответ, так что если туннель чуть медленнее, он проигрывает. IPv6 — еще одна классическая дыра: инструмент проксирует только IPv4, а запросы и соединения по IPv6 идут через провайдера как ни в чем не бывало. А некоторые провайдеры практикуют прозрачный перехват: весь трафик на порт 53 перехватывается на шлюзе и отвечает на него сам провайдер, что бы вы ни настроили.

Последствия двухслойные. Слой приватности: содержимое зашифровано, но провайдер и те, кто стоит за ним, знают каждый домен, который вы запрашивали, а один этот список говорит немало. Второй слой сильнее кусается в Китае. Отравленный DNS-ответ подсовывает неверный IP; в логе инструмента написано «подключено», но соединение ушло на адрес, который никуда не ведет, и страница так и не загружается. Заметная доля вопросов «почему не работает, хотя прокси включен» упирается именно сюда.

Как работает проверка

Прием проверки изящен. Тестовый сайт контролирует авторитетный DNS-сервер для некоторого домена. При загрузке страницы генерируется одноразовый поддомен — скажем, k3f9a2.dnsleak.example — и браузеру предлагается его запросить. Это имя никто никогда не кешировал, так что запрос обязан дойти до самого авторитетного сервера. Сервер записывает, кто спрашивал, а спрашивавший резолвер и есть ваш DNS-выход. Если он принадлежит вашему провайдеру — у вас утечка; если VPN-провайдеру или публичному резолверу — нет.

Именно так устроена страница утечки DNS в лаборатории отпечатков. Браузер разрешает шесть одноразовых имен в зоне, для которой этот сайт является авторитетным; наш DNS-сервер записывает, какой резолвер спросил о каждом из них, а страница перечисляет эти резолверы с ASN и страной и объявляет утечку, если хотя бы один из них находится не в той стране, что ваш внешний IP. Единственное условие — зона, делегированная сайту, а это отдельное развертывание, не сам веб-сервис. Там, где зона не задана, страница честно пишет «не настроено», а не гадает.

Что бы она ни показала, результат стоит перепроверить сторонним сервисом: ipleak.net, dnsleaktest.com или страницей dns-leak на browserscan. В любом результате проверьте две вещи. Перечисленные резолверы не должны принадлежать вашему местному провайдеру. В идеале резолвер и внешний IP находятся в одной стране. Выход в Гонконге в паре с пекинским резолвером China Telecom — хрестоматийная утечка.

Как закрыть

На уровне инструмента большинство современных клиентов предлагают «удаленный DNS» или что-то похожее: режим fake-ip в клиентах семейства Clash, правила маршрутизации DNS в sing-box. Идея одна и та же: либо отправлять разрешение имен тоже через туннель, либо локально возвращать адрес-заглушку и откладывать настоящий запрос на сторону выхода. Включите — и утечка в основном прекратится.

На уровне системы можно перейти на DoH (DNS over HTTPS), чтобы сами запросы были зашифрованы и провайдер не мог их ни прочитать, ни отравить, — правда, в некоторых сетях конечные точки DoH заблокированы, так что придется пробовать. IPv6 следует либо отключить, либо явно обработать в инструменте; не позволяйте ему быть путем, через который все просачивается. Еще одна частая ловушка — режим «прокси только для браузера», когда браузер ходит через туннель, а все остальное в системе — включая DNS — нет.

Почему на порты 22 и 3389 стоит взглянуть

Страница IP на этом сайте делает одно исходящее соединение с нашего сервера на ваш публичный IP на порт 22 (SSH) и 3389 (RDP) с таймаутом две секунды и сообщает: открыт, закрыт или фильтруется. Почему только эти два? Потому что их смысл наименее двусмысленный.

Снаружи у домашней сети оба должны быть закрыты или отброшены файрволом. Если один показан открытым, это обычно означает одно из двух: вы запускаете браузер на облачном сервере или VPS (например, зайдя туда по удаленному рабочему столу), либо на вашем домашнем роутере настроен проброс портов. Первое встречается часто — немало людей держат рабочий стол внутри зарубежного VPS именно ради «чистого» IP.

Проблема в том, как это читают системы оценки риска. По мнению browserscan, «пользовательский IP» с открытым 3389 сообщает платформе, что это удаленно управляемая машина, а не компьютер человека, и некоторые платформы действительно расценивают это как признак фермы или автоматизации, после чего ограничивают или банят. Мы не судим, справедливо ли это; мы указываем, что сигнал реален.

Стоит знать и другое: если вы за CGNAT (мобильный интернет, некоторые провайдеры), мы подключаемся к шлюзу оператора, а не к вашему устройству, и результат ничего не значит.

TLS-отпечатки: рукопожатие выдает вас

Наконец, проверка, которая с каждым годом значит все больше. Когда браузер открывает HTTPS-соединение, первый пакет — ClientHello, в котором перечислены поддерживаемые клиентом версии TLS, наборы шифров в порядке предпочтения, расширения и их порядок, поддерживаемые эллиптические кривые и форматы точек. Для конкретного клиента эта комбинация довольно фиксирована: у Chrome свой порядок, у Firefox другой, библиотека requests для Python выглядит еще иначе. Склейте эти поля, посчитайте MD5 — и получите отпечаток JA3. JA4 — более новый формат, более структурированный и более устойчивый к рандомизации. У HTTP/2 есть аналог: значения во фрейме SETTINGS, WINDOW_UPDATE и порядок псевдозаголовков, которые Akamai оформила в h2-отпечаток.

Применение прямолинейное. Запрос, у которого User-Agent говорит «Chrome», а TLS-рукопожатие выглядит как стандартная библиотека Go, почти наверняка скрипт. Это один из самых надежных способов увидеть подмененный UA насквозь, и антибот-системы и системы борьбы с мошенничеством сильно на него опираются.

Для тех, кто обходит блокировки, значение такое: некоторые прокси и ретрансляторы терминируют TLS посередине и начинают новое рукопожатие, так что сервер видит их отпечаток, а не вашего браузера. Некоторые инструменты намеренно имитируют отпечаток Chrome, чтобы избежать блокировки. Чтобы вообще что-то из этого увидеть, сервер должен терминировать TLS сам: за CDN он видит только рукопожатие самой CDN. Поэтому страница TLS на этом сайте делает один кросс-доменный запрос к отдельному хосту без CDN, где рукопожатие и терминируется, и показывает JA3, JA4 и отпечаток HTTP/2, а заодно — встречается ли такой JA4 у того семейства браузеров, которое заявляет ваш User-Agent, по нашей же статистике. Если этот хост не развернут или недоступен из вашей сети, страница откатывается к стороннему check.ja3.zone: только JA3, без сравнения.

Вопросы и ответы

Если прокси включен, DNS автоматически идет через него? Не обязательно; зависит от настроек инструмента. С настройками по умолчанию многие клиенты проксируют соединения, но не запросы имен. Один прогон на тестовых сайтах выше расставляет все по местам.

Что означает «фильтруется» для порта? Никакого ответа в течение двух секунд — обычно файрвол отбрасывает пакет. Для домашней сети это нормально и даже предпочтительно.

Почему страница DNS или TLS пишет «не настроено»? Обеим проверкам нужно кое-что за пределами веб-приложения: одной — DNS-зона, делегированная сайту, другой — хост, который сам терминирует TLS. Если на конкретной установке этого нет, страница так и говорит, вместо того чтобы гадать; страница TLS при этом все равно показывает JA3 с check.ja3.zone.

Можно ли подделать JA3? Да. Некоторые библиотеки специально имитируют рукопожатия популярных браузеров, отчасти поэтому и появился JA4. Но подделывать его согласованно везде непросто, и он остается полезным сигналом.