Проверка анонимности прокси: Тест на утечку VPN

Потому что эти два утверждения получены с разных уровней, и только одно из них можно подделать в браузере. User-Agent — это просто текстовая строка, которую может изменить любой браузер или расширение. Пакет TCP SYN, открывающий соединение, формируется ядром операционной системы, и порядок его опций, масштаб окна и поведение меток времени различаются в Linux, Windows и Apple. Устройства Apple отправляют опции TCP в порядке MSS, NOP, WS, NOP, NOP, TS, SACK_PERM, EOL. Linux отправляет MSS, SACK_PERM, TS, NOP, WS. Если ваш браузер заявляет iOS, но сигнатура ядра принадлежит Linux, дошедшее до нас TCP-соединение было открыто не вашим телефоном. Оно было пересоздано другой машиной — почти всегда прокси-сервером или пограничным узлом CDN.

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

Максимальный размер сегмента (MSS), объявленный в пакете SYN, позволяет вычислить MTU маршрута: MTU равен MSS плюс 40 байт для IPv4 и плюс 60 байт для IPv6. Различные типы каналов имеют характерные значения: домашний интернет по PPPoE — 1492; мобильные операторы обычно находятся в диапазоне от 1400 до 1430; туннели WireGuard по умолчанию используют 1420; а чистый Ethernet — на практике сервер в дата-центре — 1500. Таким образом, отчет мобильного телефона со значением 1500 является явным противоречием: ни одна сотовая сеть не выдает такое значение. На настольном компьютере это число менее показательно, так как офисные сети и оптоволокно без PPPoE также достигают 1500, поэтому мы придаем этому признаку гораздо меньший вес.

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

Потому что репутация IP-адреса и поведение протокола независимы друг от друга. Покупка резидентного IP меняет то, что базы данных говорят о вашем адресе, но не меняет способ формирования пакетов на выходном сервере. Если этот сервер работает на Linux, он продолжает отправлять опции TCP Linux, объявлять MTU дата-центра и завершать TLS со своим собственным отпечатком. Система оценки рисков, которая смотрит только на списки IP, увидит чистый резидентный адрес; система, анализирующая стек протоколов, увидит сервер. Это самое распространенное заблуждение, и именно поэтому наш отчет строго разделяет доказательства, подтвержденные протоколом, и признаки, основанные исключительно на репутации адреса.

💡 Подробную информацию об ASN и показателе риска смотрите на Главной странице MyIPDNS.

Это означает, что мы не нашли противоречий на уровне протоколов и опираемся исключительно на данные баз IP-адресов о вашей точке выхода. Такое происходит, когда ваше собственное устройство и прокси-сервер работают на одной операционной системе. Компьютер с Linux за Linux-прокси создает однородную сигнатуру Linux, поэтому кросс-уровневому анализу не с чем сравнивать. Мы честно указываем это ограничение: доказательства с меткой "protocol" подтверждены анализом пакетов, а с меткой "reputation" — нет. Вердикт с низкой степенью уверенности, основанный только на репутации, следует воспринимать как предположение, а не как окончательное доказательство.

💡 Разработчики могут получить структурированные данные через наш Бесплатный IP API.

Некоторые признаки зависят от конфигурации, а некоторые являются физическими фактами. MTU дата-центра можно скрыть, установив MTU туннельного интерфейса на вашем сервере в диапазоне от 1420 до 1450, что сделает маршрут похожим на обычный пользовательский туннель. Общие смещения меток времени TCP исчезнут, если обновить ядро выходного сервера до версии, которая генерирует случайное смещение для каждого соединения, а не вычисляет его по хэшу пары адресов. Несоответствие между операционной системой выхода и заявленной в браузере невозможно исправить настройками клиента: оно исчезнет только в том случае, если сервер выхода использует ту же ОС, либо если опции SYN перезаписываются на выходе. Никакие расширения браузера не могут это изменить, так как эти данные генерируются не браузером.

💡 После изменения настроек вернитесь на Главную страницу для повторной проверки.

Нет. Все выводы строятся исключительно на основе пакетов, которые доходят до наших зондов и содержат только ваш исходящий адрес. Мы часто можем определить, что соединение было пересоздано по пути, и описать характеристики промежуточного узла, но адрес исходного устройства отсутствует в этом трафике и не может быть из него восстановлен. Отдельно тесты WebRTC и DNS на этом сайте могут выявить локальный адрес, если ваш браузер или DNS-резолвер допускают утечку, однако это отдельный механизм, о котором сообщается отдельно.

💡 Диагностика расхождений маршрутизации и DNS доступна в Диагностике утечек маршрута.