Тест на утечку DNS и IP: Проверьте безопасность сети

Многие полагают, что покупка «резидентного прокси» позволяет полностью замаскироваться под обычного домашнего пользователя. Однако современные антифрод-системы оценивают не только статические метки в базах GeoIP (IP2Location, MaxMind и др.). Даже если IP-адрес принадлежит домашнему провайдеру, выходной узел почти всегда работает на облачном сервере под управлением Linux, создавая явные межслойные противоречия: во-первых, сигнатура стека TCP транспортного уровня — в начальном пакете SYN выходной сервер отправляет стандартный порядок опций Linux (MSS, SACK_PERM, TS, NOP, WS), а не порядок, характерный для Windows или Apple. Во-вторых, MTU маршрута: домашний интернет по PPPoE обычно имеет MTU 1492 (мобильные сети — от 1400 до 1430), тогда как серверные сети дата-центров используют стандартный MTU 1500 (MSS=1460). Когда система риска видит резидентный IP в сочетании с MTU дата-центра и стеком TCP Linux, подключение классифицируется как автоматизированный прокси.

💡 Чтобы проверить точку терминации TCP вашего соединения, воспользуйтесь Тестом анонимности прокси.

Сам IP-адрес не содержит физических координат. Отображаемое местоположение зависит от используемой базы данных GeoIP и частоты ее обновления: во-первых, различия источников данных и моделей — провайдеры (MaxMind, IP2Location, DB-IP) по-разному анализируют анонсы BGP, данные Whois и сетевые задержки, а периодичность обновлений варьируется от нескольких дней до месяцев. Во-вторых, Anycast-маршрутизация и CDN — такие сети, как Cloudflare, анонсируют одинаковые диапазоны IP из сотен дата-центров по всему миру, направляя трафик на ближайший пограничный узел. В-третьих, перераспределение IP-диапазонов между странами — при передаче блоков адресов устаревшие базы продолжают отображать прежнюю локацию. Наш сервис сопоставляет несколько баз данных и использует трилатерацию по задержке RTT со скоростью света для проверки физического местоположения.

Показатель фрода IP (Fraud Score / Risk Score) — это числовой индекс (обычно от 0 до 100), отражающий вероятность того, что подключение является ботом, вредоносным скриптом или фальсифицированным трафиком. Ключевые факторы оценки включают: во-первых, репутационную историю и черные списки — участие IP в атаках подбора паролей, чрезмерном парсинге, рассылке спама или сканировании портов за последние 24–72 часа. Во-вторых, тип ASN и инфраструктуры — IP-адреса дата-центров (хостинга), публичных прокси и VPN имеют значительно более высокий базовый риск по сравнению с домашними или мобильными сетями. В-третьих, согласованность протоколов и конечных точек — разделение выходов IPv4/IPv6 в рамках одной сессии, географическое расхождение DNS-серверов или утечка локального IP через WebRTC.

💡 Чтобы выявить утечки маршрутизации, повышающие ваш показатель риска, пройдите Тест раздельного туннелирования.

Даже при активном VPN или прокси реальные данные могут утекать по побочным каналам: во-первых, утечка DNS — когда браузер запрашивает доменное имя, если прокси-клиент не перехватывает DNS-запросы на уровне ОС, незашифрованные запросы отправляются напрямую на DNS-сервер вашего интернет-провайдера (ISP), раскрывая посещаемые сайты и ваше реальное местоположение. Во-вторых, утечка WebRTC — протокол WebRTC предназначен для связи в реальном времени и для установки P2P-соединений отправляет пакеты STUN по протоколу UDP в обход стандартных HTTP/SOCKS прокси, раскрывая локальные и публичные IP устройства. На главной странице нашего сервиса выполняется диагностика DNS-выхода и состояния WebRTC в реальном времени.

💡 Для глубокой проверки аппаратной целостности Canvas, Audio и WebRTC откройте Тест цифрового отпечатка браузера.

Панель сетевого стека на главной странице параллельно запускает три взаимосвязанных зонда: один обращается к домену исключительно с A-записями (iptestv4.myipdns.com), второй — к домену исключительно с AAAA-записями (iptestv6.myipdns.com), а третий — к домену двойного стека с обоими семействами записей. Первые два зонда принудительные: каждое из этих доменных имен резолвится только в одно семейство адресов, не оставляя системе выбора, что позволяет независимо зафиксировать ваши реальные выходные адреса в IPv4 и IPv6. Третий зонд ничего не навязывает; напротив, он фиксирует, какое семейство адресов ваша система выбрала самостоятельно, что и отражено в колонке «Приоритетный протокол»: этот результат определяется алгоритмом выбора адресов операционной системы и браузера (Happy Eyeballs, RFC 8305: при доступности обоих стеков сначала проверяется IPv6, а IPv4 используется лишь как резерв), а не нашими настройками. Сопоставление всех трех показателей критически важно, поскольку многие прокси-клиенты и VPN перехватывают только IPv4: если ваш выход IPv4 находится в ASN провайдера прокси, а выход IPv6 по-прежнему принадлежит вашему домашнему провайдеру, при этом приоритетным протоколом указан IPv6, то при открытии сайтов с двойным стеком основная часть трафика вовсе не проходит через туннель — это самый частый сценарий, когда «VPN включен, но реальная личность раскрыта», причем без каких-либо уведомлений об ошибках.

⚠ Мы можем лишь констатировать, разделены ли ваши выходы по разным сетям; мы не можем указывать, как именно следует настроить ваше прокси-приложение. Справедливо и обратное: статус «недоступен» для IPv6 не означает абсолютную безопасность; это может свидетельствовать как об отсутствии IPv6 у провайдера, так и о полном отключении IPv6 клиентом прокси — последнее как раз зачастую является корректным решением.

Мы не считываем локальные настройки вашей системы: браузер технически не имеет к ним доступа, и любые веб-страницы, заявляющие об обратном, строят догадки. Настоящий метод заключается в проведении обратного теста: наш сервис содержит собственный авторитетный DNS-сервер и при каждой проверке генерирует уникальный случайный субдомен (вида k3f9x2ab.leakv4.myipdns.com) для резолва вашим браузером. Это имя создается единственный раз в мире и гарантированно отсутствует во всех кэшах, поэтому цепочка рекурсивных запросов обязана дойти напрямую до нашего авторитетного сервера; мы фиксируем, кто именно пришел с запросом, и передаем этот адрес обратно на страницу. Таким образом, в колонке «Выход DNS» отображается фактический сетевой адрес выхода вашего рекурсивного резолвера, а не тот адрес, который вы указали в настройках системы: если вы задали 8.8.8.8, с запросом к нам обратится конкретный выходной узел этого кластера, который вполне может располагаться в другой стране; крупные публичные службы используют Anycast и кластеризацию, поэтому появление нескольких разных адресов в рамках одной проверки совершенно нормально. Истинный критерий заключается не в совпадении адресов, а в следующем: если этот выход находится в сети вашего собственного интернет-провайдера, в то время как IP-выход направлен через прокси — это указывает на то, что DNS-запросы пошли в обход туннеля.

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

С помощью технологии WebRTC одиночные зонды направляются на несколько STUN-серверов для сбора возвращенных кандидатов srflx — то есть публичного IP и порта, которые фактически видит удаленный узел после трансляции NAT. Критерий оценки строго один: кандидаты группируются по транслированному публичному IP; если под одним IP зафиксировано два или более различных порта, соединение определяется как симметричный NAT (для каждого нового адресата назначается новый внешний порт); в противном случае фиксируется конусный NAT (один и тот же внутренний порт постоянно транслируется в один и тот же публичный порт). Предварительная группировка перед сопоставлением портов введена намеренно: в условиях раздельного туннелирования разные STUN-серверы могут опрашиваться через разные маршруты, что приводит к несовпадению портов; однако это вызвано различием путей, а не спецификой NAT — без группировки такие подключения ошибочно классифицировались бы как симметричные. Статус «Неизвестно» имеет две причины: во-первых, отсутствие кандидатов srflx в течение 4-секундного таймаута (WebRTC отключен в браузере, заблокирован расширениями или фильтруется исходящий UDP); во-вторых, получение лишь одного кандидата, чей публичный IP не совпадает с входным IP на наш сайт, когда невозможно отличить дедупликацию браузера от раздельного туннелирования, и мы намеренно выводим неопределенный статус.

⚠ Честное уточнение: мы различаем только две категории — конусный и симметричный NAT, без выделения полного, ограниченного или ограниченного по порту конуса. Классификация RFC 3489 на четыре типа требует активного управления комбинациями портов источника и адресов назначения при последовательных зондированиях, а WebRTC в браузере не предоставляет подобного контроля; веб-инструменты, сообщающие об одном из четырех типов, чаще всего лишь по-новому маркируют эти два результата.

Каждая диагностика на главной странице параллельно запускает шесть зондов, направленных к различным доменам: один только по IPv4, один только по IPv6, два для сбора отпечатков сетевого стека по IPv4 и IPv6 соответственно, один к двухстековому домену для определения приоритетного семейства и один строго принудительный по протоколу HTTP/1.1. Это не дублирующие запросы; каждый зонд собирает принципиально разные метрики. Их раздельная отправка необходима, так как наш анализ строится на межсетевом сопоставлении: одно и то же устройство демонстрирует разные признаки стека в IPv4 по сравнению с IPv6, а также в HTTP/1.1 по сравнению с HTTP/2 (и HTTP/3 при его доступности), сопоставить которые можно лишь собрав раздельно. При этом параллельность нужна не для скорости: при последовательной отправке переключение сети, смена прокси или переподключение туннеля объединили бы данные несуществующей гибридной машины; одновременная отправка гарантирует, что все шесть зондов зафиксируют один и тот же маршрут в один и тот же момент времени. Зонд HTTP/1.1 намеренно выполняет ровно один запрос: в HTTP/1.1 отсутствует динамическая таблица HPACK, поэтому повторные запросы не несут новой энтропии, тогда как одиночный запрос гарантирует точное соответствие заголовков единой записи измерений.

⚠ Платой за это является одновременное подключение к нескольким поддоменам при первой загрузке, что иногда блокируется блокировщиками рекламы или строгими расширениями приватности. В этом случае соответствующий индикатор отобразит серую точку в неопределенном статусе; мы ни при каких обстоятельствах не подставляем данные других зондов для имитации кажущегося полным результата.