Открыв страницу проверки IP, вы видите, что адрес уже стал ожидаемым выходом, и легко подумать, что все настройки вступили в силу. На самом деле это лишь означает, что данный веб-запрос использовал этот адрес. Разрешение доменных имён, связь WebRTC и запросы IPv6 не обязательно идут по одному и тому же пути.
Ключевой момент при определении утечки IP или DNS — не «сколько адресов появилось на странице», а не выходит ли информация или трафик за пределы пути, который вы ожидали защитить. Появление адреса внутренней сети, публичного DNS или названия региона, отличного от выхода, само по себе не является доказательством утечки.
Эта статья подходит для проверки ваших устройств, браузеров и сетевых настроек. Результаты проверки отражают только наблюдаемую в данный момент среду и не должны рассматриваться как гарантия конфиденциальности для всех приложений на устройстве.
Сначала определите, какой трафик вы хотите защитить
Перед началом теста ответьте на простой вопрос: что вы настроили — прокси для браузера, системный прокси или VPN, перехватывающий сетевую маршрутизацию?
Их зона покрытия может различаться. Расширение браузера не обязательно обрабатывает другие приложения; системный прокси не означает, что каждый протокол будет следовать настройкам прокси. Покрывает ли VPN IPv6, DNS и разделённый трафик, также зависит от конкретной реализации и конфигурации.
Если вы намеренно разрешили какому-то приложению прямое соединение, то его выход через исходный канал не обязательно является сбоем. Но если вы ожидаете, что «весь исходящий трафик использует указанный выход», то такое же явление требует дальнейшего анализа.
Рекомендуется сначала сохранить базовые показатели: публичный IPv4 и IPv6 до включения целевой конфигурации, а также резолверы, наблюдаемые при проверке DNS. Базовые данные используются для сравнения до и после и не нуждаются в публикации; особенно в корпоративных сетях не следует раскрывать внутренние адреса и скриншоты конфигурации.
WebRTC: сначала разберитесь с адресами-кандидатами, затем определите, раскрывает ли он выход
WebRTC позволяет браузеру выполнять коммуникацию в реальном времени — аудио, видео и данные. Для установления соединения он собирает возможные сетевые пути, то есть ICE-кандидатов.
Документация MDN по типам кандидатов различает типы host, srflx, prflx и relay. Для обычного пользователя важнее всего различать информацию о локальных интерфейсах, информацию, наблюдаемую после трансляции адресов, и адреса ретрансляционных серверов. Раскрытие кандидатов веб-странице также зависит от политики конфиденциальности WebRTC браузера.
Результаты, появляющиеся при проверке | Более разумная интерпретация |
|---|---|
Частные IPv4, такие как 192.168.x.x, 10.x.x.x | Может отражать информацию о локальной сети, но не может служить единственным доказательством утечки публичного выхода |
Имена .local | Возможно, следствие приватной обработки локальных кандидатов браузером, не равно реальному публичному IP |
Публичный адрес, совпадающий с ожидаемым выходом | Соответствует ожиданиям данной проверки, но не означает, что весь трафик проверен |
Подтверждённый публичный адрес исходной сети | Если он должен быть защищён, это важный сигнал утечки, требующий проверки |
Адрес TURN-ретранслятора | Показывает, что соответствующие кандидаты проходят через ретранслятор, но не является прямым доказательством исходного публичного адреса пользователя |
Раскрытие исходного сетевого адреса через WebRTC не является выдумкой. RFC 8828 обсуждает проблему раскрытия IP-информации в случаях разделённого VPN, нескольких сетевых интерфейсов и прокси приложений. Однако реализация браузера, разрешения и сетевые политики влияют на фактическое поведение, поэтому нельзя прямо переносить выводы тестов из старых браузеров на все устройства.
В Проверка утечек WebRTC, если вы видите публичный адрес, который не соответствует ожиданиям, сначала сравните с базовым уровнем, затем проверьте, к какой сети он принадлежит. Не делайте вывод только на основании того, что «показан второй адрес», и не приравнивайте «кандидаты не собраны» к абсолютной безопасности — связь может быть заблокирована или тест не завершён, что также даёт пустой результат.
DNS: что означает, если виден резолвер оператора?
Прежде чем браузер обратится к домену, ему обычно нужно получить соответствующий адрес. Утечка DNS касается того, выполняется ли этот шаг в соответствии с ожидаемой политикой разрешения, и может ли сторона, которой не следует видеть запрос, получить к нему доступ.
Обычные тесты на утечку DNS заставляют браузер запрашивать набор тестовых доменов, а затем наблюдают источник запросов со стороны авторитетного DNS. Страница обычно показывает выход рекурсивной цепочки разрешения, а не прямое считывание конфигурации DNS вашего устройства.
Это означает, что после обнаружения адреса DNS нельзя сразу утверждать, что «локальный DNS-сервер — это он». Рекурсивная пересылка, публичные сервисы разрешения и развёртывание Anycast могут сделать результат сложнее, чем в интерфейсе системных настроек.
В особенности не смотрите только на название страны: геолокация DNS-выхода по базе данных отличается от веб-выхода, и её недостаточно для доказательства утечки. Следует дополнительно проверить оператора резолвера, способ маршрутизации сервиса и соответствие вашим целям конфигурации.
Если вы ожидаете, что используется только путь разрешения, заданный VPN, но тест постоянно наблюдает выход резолвера исходного оператора сети, это сигнал для расследования. Если вы самостоятельно настроили какой-либо публичный DNS, то его обнаружение не обязательно является аномалией.
Можно использовать Проверка утечек DNS для сравнения до и после. Если появляется несколько резолверов, сначала проверьте, нет ли переопределения или одновременного использования между «безопасным DNS» браузера, DNS операционной системы, DNS VPN и настройками раздельного туннелирования.
Если включён DoH, то утечки не будет?
DoH решает проблему шифрования передачи DNS-запросов, но не решает автоматически все вопросы маршрутизации и доверия. Документация Cloudflare описывает инкапсуляцию DNS-запросов в HTTPS, но «передача зашифрована» не означает «запрос точно пошёл через указанный вами VPN».
Сервис разрешения всё равно обрабатывает ваши запросы. Некоторые развёртывания могут также использовать EDNS Client Subnet для передачи информации о префиксе клиентской сети в рекурсивном запросе; этот механизм и его влияние на конфиденциальность описаны в RFC 7871. Если обычный DNS-тест явно не сообщает об этом параметре, не предполагайте, что ECS уже проверен.
IPv6: правильный выход IPv4 не означает, что второй стек адресов тоже корректен
Многие сети предоставляют одновременно IPv4 и IPv6. Если какой-то прокси или VPN обрабатывает только IPv4, а устройство по-прежнему может использовать IPv6 напрямую через исходную сеть, то целевые сервисы с поддержкой IPv6 могут наблюдать другой путь выхода.
Однако «адреса IPv4 и IPv6 различаются» — это нормальное явление. Они принадлежат к разным системам адресации, и нельзя судить о действенности защиты по схожести текста адресов.
Следует сравнивать: принадлежность к сети для обоих протоколов, фактическое соответствие маршрутизации ожиданиям, и не указывает ли IPv6 по-прежнему на исходную сеть. Изменение временных адресов IPv6 само по себе также не означает утечку.
В Проверка среды браузера отдельно посмотрите доступную информацию IPv4 и IPv6. Если тест IPv6 не завершён, можно пометить только как «не подтверждено»; это не то же самое, что «подтверждена недоступность IPv6».
Повторяемая последовательность диагностики
1. Сравните до и после на одном устройстве и в одном браузере
Запишите информацию о выходе без целевой конфигурации, затем включите конфигурацию и проверьте снова. Во время теста не меняйте одновременно Wi-Fi, прокси браузера и DNS, иначе будет трудно определить, какой шаг вызвал изменение.
2. Проверьте отдельно веб, WebRTC, DNS и IPv6
Записывайте результаты четырёх групп отдельно: публичный выход, наблюдаемый веб-страницей, кандидаты WebRTC, источник DNS-запросов, доступность и выход IPv6. Не заменяйте другие пункты зелёным статусом одного из них.
3. Найдите настройки по аномальному пути
WebRTC раскрыл публичный адрес исходной сети — проверьте охват прокси, политику WebRTC и используется ли в VPN раздельное туннелирование. DNS не соответствует ожиданиям — проверьте настройки разрешения браузера и системы, а также поведение восстановления DNS после разрыва VPN. IPv6 по-прежнему идёт через исходную сеть — проверьте поддержку IPv6 в VPN и связанные маршруты.
Меняйте за раз только один связанный параметр, затем повторяйте тест. При необходимости решения долгосрочной рабочей задачи сохраняйте время, состояние конфигурации и краткий итог результата — обычно это полезнее для локализации, чем один скриншот с «красным предупреждением».
4. Проверьте поведение после повторного подключения
Повторное подключение к сети, пробуждение устройства из спящего режима и переподключение VPN могут изменить путь. Если позволяют условия, проверьте снова после этих обычных сценариев использования. Один успешный тест доказывает лишь, что наблюдавшееся поведение соответствовало ожиданиям в тот момент, и не заменяет последующую проверку стабильности.
Не рекомендуется с самого начала отключать все функции
Прямое отключение WebRTC может повлиять на звонки и конференции в браузере; прямое отключение IPv6 также может скрыть проблемы конфигурации. Стоит ли это делать, зависит от ваших реальных потребностей и приемлемой потери функциональности, а не только от желания убрать несколько строк со страницы проверки.
Более надёжный подход — сначала определить объём защиты, а затем исправить соответствующие маршруты, разрешение или настройки браузера. Корпоративные устройства должны также следовать политикам администратора и не должны самостоятельно обходить установленные сетевые конфигурации и конфигурации безопасности.
Может ли приватное окно предотвратить эти утечки?
Нельзя рассматривать режим инкогнито как сетевой туннель. Он в основном меняет обработку локальных данных сеанса, таких как история просмотра и файлы cookie, но не перехватывает автоматически DNS, WebRTC или маршрутизацию IPv6.
Означает ли невозможность обнаружить исходный IP-адрес полную анонимность?
Нет. Маршрут IP-адреса — лишь часть конфиденциальности. Вход в учётную запись, файлы cookie, отпечаток браузера и добровольно предоставленная информация могут позволить сервису идентифицировать или связать посещение.
После завершения этой проверки разумным выводом должно быть: «При текущей конфигурации и условиях тестирования наблюдаемые сетевые пути соответствуют ожиданиям». Это точнее, чем фраза без указания области применения «нулевые утечки, полная анонимность», и лучше помогает в дальнейшем использовании.
Сценарий разделения трафика: как интерпретировать четыре разных результата на одном устройстве
Предположим, вы настроили разделение по доменам или одновременно используете VPN и локальное прямое подключение. В одном тесте HTTP-выход показывает адрес прокси-узла A, DNS-проверка — адрес рекурсивного сервера B, в кандидатах WebRTC появились публичный адрес C исходной сети и TURN-адрес D, а IPv6 по-прежнему идёт по линии оператора. Такие результаты легко ошибочно принять за «четыре полные утечки». На самом деле, возможно, у каждого из них просто свой маршрут. Важно не количество IP-адресов, а соответствие этих путей вашим ожиданиям.
В этом примере, если вы хотите, чтобы HTTP-трафик веб-страниц шёл через прокси, выход A может соответствовать конфигурации; нужно отдельно подтвердить, должен ли DNS идти напрямую. Если в кандидатах WebRTC, которые может прочитать страница, появляется публичный адрес C исходной сети, это уже означает, что страница в данном тесте может узнать C, и не нужно ждать, пока медиасоединение фактически использует его, чтобы считать это раскрытием. Является ли это утечкой, не соответствующей требованиям, зависит от того, требуется ли скрыть этот адрес от данной страницы.
Кандидатов mDNS нужно особенно различать. Браузеры часто используют случайно сгенерированные имена .local для представления локальных сетевых интерфейсов, чтобы не раскрывать напрямую реальную информацию о локальной сети. Если на странице проверки WebRTC вы видите запись вида «2f8c…local», её следует понимать как меру конфиденциальности для локального кандидата, а не как ваш публичный IP-адрес или имя хоста. Считать её доказательством утечки — распространённое заблуждение. Если одновременно присутствует публичный адрес исходной сети и это приложение должно быть защищено туннелем, это уже сигнал раскрытия, требующий серьёзной проверки.
IPv6 также нужно фиксировать отдельно. Если IPv4-выход идёт через прокси A, но IPv6 по-прежнему идёт по прямому каналу оператора, целевые сайты с поддержкой dual-stack могут одновременно или в первую очередь наблюдать ваш адрес оператора через IPv6. Это не обязательно вызвано ошибкой конфигурации прокси; многие клиенты, использующие разделение по CIDR или проксирующие только IPv4, по умолчанию не перехватывают маршрутизацию IPv6. В этом случае не спешите делать вывод об «утечке IPv6», а сначала уточните, заявляет ли VPN или прокси о покрытии IPv6, затем проверьте, есть ли локальный маршрут по умолчанию для IPv6, указывающий в туннель.
Различия в рекурсивных DNS-серверах можно оценить с помощью информации ASN и RDAP. Если адрес B принадлежит публичному сервису разрешения, который вы сами выбрали, то его отличие от HTTP-выхода — нормальное явление; если он принадлежит оператору исходной сети и вы хотели направить трафик разрешения в туннель, это аномалия, требующая изучения. Сервисы разрешения с развёртыванием Anycast могут показывать разные узлы в разных регионах, поэтому нельзя судить о прямом DNS только по изменению географического положения. Следует обращать внимание на название оператора, принадлежность ASN и на то, наблюдаются ли на авторитетной стороне тестового домена источники запросов, не соответствующие ожиданиям.
При таком сосуществовании нескольких выходов первым делом не отключайте функции, а запишите «ожидания». Какие приложения должны идти через прокси, какие — напрямую; кто должен обрабатывать DNS; должен ли IPv6 быть покрыт туннелем или разрешён напрямую; разрешено ли WebRTC собирать локальных кандидатов при подключении к VPN. После завершения одного измерения сравните с базовым уровнем. Если обнаружено несоответствие ожиданиям, вернитесь к конкретным настройкам и корректируйте по одному. Меняйте только одну переменную за раз, например сначала DNS, затем повторите тест, чтобы определить, какое правило вызвало различие.
Повторные измерения и восстановление после обрыва: сделайте результаты проверки воспроизводимыми
Одно успешное прохождение проверки лишь означает, что среда в тот момент соответствовала ожиданиям. Переподключение VPN, пробуждение системы, изменение разрешений браузера могут изменить маршрут. Рекомендуется повторять измерения после обычных сценариев использования: после отключения и повторного подключения VPN, после выхода из спящего режима, после переключения между Wi-Fi и мобильной сетью отдельно проверяйте HTTP-выход, источник DNS, кандидатов WebRTC и состояние IPv6. Стабильность этих четырёх результатов ценнее, чем однократный «полностью зелёный» статус.
При каждом измерении меняйте только одну переменную. Например, если сегодня вы меняете только настройки WebRTC, оставьте DNS и VPN без изменений; если завтра меняете только IPv6, повторите тест всех четырёх пунктов. Если одновременно изменить «безопасный DNS» в браузере, разделение прокси и системный переключатель IPv6, при появлении нестабильного поведения будет трудно отследить, что именно вызвало изменение. Записывайте время, состояние конфигурации и краткое резюме результатов — это полезнее для долгосрочного обслуживания, чем один красный скриншот с предупреждением.
Разрешения браузера напрямую влияют на кандидатов WebRTC. Если сайт не имеет разрешения на микрофон или камеру, браузер может не собирать кандидатов локальных интерфейсов; как только доступ к аудио/видео предоставлен, диапазон сбора кандидатов может расшириться. Поэтому тестируйте WebRTC до и после предоставления разрешений, чтобы увидеть изменения в списке кандидатов. Не считайте, что пути раскрытия через WebRTC отсутствуют, только потому что при отсутствии разрешений страница не показывает кандидатов — это принятие «не измерено» за «защищено». Аналогично, окно инкогнито не меняет сетевую маршрутизацию и не может считаться мерой защиты от утечек.
IPv6 следует обрабатывать явно в соответствии с потребностями: если нужна полная защита dual-stack, выберите и настройте туннель с поддержкой IPv6, проверьте фактическую маршрутизацию и межсетевой экран; если продукт поддерживает только IPv4, уточните, какую политику блокировки или обхода он применяет для IPv6. Простое добавление маршрута по умолчанию не гарантирует защиту всех приложений и состояний обрыва. Полное отключение IPv6 также может повлиять на совместимость; сначала поймите возможности клиента и сохраните обратимую конфигурацию, затем отдельно проверьте нормальное состояние, переподключение и обрыв.
Приёмка восстановления после обрыва должна включать стратегию «kill switch». Если какой-то VPN заявляет, что после обрыва блокирует весь исходящий трафик, проверьте, что при разрыве сети DNS-запросы также завершаются ошибкой, а не возвращаются к резолверу исходной сети. Некоторые реализации обрывают только IPv4 TCP, но позволяют IPv6 или DNS продолжать идти по исходной линии — такая «частичная защита» оставляет окно наблюдения. Это можно подтвердить, поочерёдно вызывая события обрыва и наблюдая за поведением HTTP-, DNS- и IPv6-запросов.
«Промах» в результатах проверки не означает «безопасно». Если IPv6 показывает невозможность подключения из-за отсутствия поддержки сети, это можно пометить только как «не подтверждено», а не как «подтверждено отсутствие утечки IPv6». Путь можно считать прошедшим проверку, только если тест был отправлен и результат соответствует ожиданиям. В каждом измерении указывайте условия теста, например версию браузера, режим прокси, протокол VPN и сетевую среду, чтобы обеспечить основу для последующего воспроизведения.
В более сложных средах, таких как CGNAT, который может изменять соответствие между публичным выходом и внутренним адресом, можно обратиться к Как узнать публичный IP и проверить подключение на CGNAT для понимания уровней NAT; а некоторые инструменты безопасности могут ошибочно принимать нормальные явления за признаки VPN или прокси, поэтому стоит обратиться к IP определён как VPN или прокси: как проверить ошибку для дальнейшей интерпретации вывода инструментов. Использование этих материалов вместе помогает уменьшить ошибочные суждения, вызванные типом адреса или логикой обнаружения.
В итоге соберите результаты проверки в единый документ приёмки: ясен ли ожидаемый путь, соответствует ли каждый тип трафика ожиданиям в трёх состояниях — нормальном, при переподключении и при обрыве, и локализованы ли аномалии до конкретных настроек. Такой вывод — «в текущих условиях и в рамках тестирования наблюдаемый сетевой путь соответствует ожиданиям» — ценнее любого одноразового зелёного индикатора.
