Если вы видите какие-либо из приведенных ниже симптомов даже после включения VPN, заподозрите утечку DNS или утечку WebRTC. Утечка — это когда информация, которая должна пройти по пути VPN, покидает этот путь (также называемая эксфильтрацией).
- IP-адрес VPN-сервера отображается на странице проверки IP, а в DNS-тесте отображается DNS-сервер телекоммуникационной компании или маршрутизатора.
- Адрес IPv4 изменился, но адрес IPv6 остался таким же, как и до отключения VPN.
- На тестовой странице WebRTC общедоступный IP-адрес отображается таким, каким он был до отключения VPN.
- Исходный IP-адрес виден только сразу после переключения с Wi-Fi на мобильные данные или выхода из спящего режима.
- Я включил StageVPN для Chrome, но другие браузеры и программы для ПК подключаются, используя исходный IP-адрес.
- Даже при включенном VPN сайт отображает язык и контент в зависимости от исходного региона (это может быть связано с настройками учетной записи или файлов cookie).
Утечка DNS — явление, при котором веб-коммуникация при включенном VPN проходит через туннель, но из туннеля выходят только DNS-запросы, а доменное имя видно DNS-серверу телекоммуникационной компании или Wi-Fi. Утечка WebRTC — это явление, при котором WebRTC браузера отправляет запрос STUN непосредственно из VPN/прокси, позволяя веб-странице обнаружить фактический общедоступный IP-адрес. Ни одно из этих явлений не означает утечку содержимого страницы. Однако он показывает, «кто и куда имеет доступ». Эта статья начинается с симптомов и проходит шесть этапов диагностики, разрешения причины и повторного обследования.
Диагностика: как проверить утечку за 6 шагов
Принцип проверки на утечку заключается в сравнении значений при выключенном VPN и при включенном. Сравните IP-адрес, указанный на сайте, сервер, получивший DNS-запрос, и адрес-кандидат WebRTC. Если исходные значения видны даже после включения VPN — это утечка. Тестирование имеет смысл только на тех устройствах и браузерах, которые вы действительно используете. Даже если у вас нет специального тестового сайта, вы можете проверить большинство вещей, просто используя браузер. Страница проверки IP — это веб-страница, на экране которой отображается общедоступный IP-адрес подключенного человека. Найти его можно в поисковике как «Проверить IP». Таким же образом найдите страницу теста утечки DNS и страницу теста WebRTC. Принцип один и тот же независимо от того, какую страницу вы используете, поэтому вам не нужно полагаться на конкретный сайт.
- Отключите VPN и запишите свой IP. Откройте страницу проверки IP и запишите общедоступный адрес IPv4 и, если он есть, адрес IPv6. Это значение является основой для всех последующих сравнений.
- Включите VPN и сравните IP-адреса. После проверки индикатора завершения подключения в приложении StageVPN или зеленого индикатора включения на значке StageVPN для Chrome снова откройте ту же страницу. IPv4 следует заменить адресом вашего VPN-сервера.
- Проверьте свой DNS-сервер. Откройте страницу тестирования на утечку DNS. Эти страницы запрашивают случайные поддомены, а затем показывают DNS-сервер, отправивший запрос. Если вы видите серверы вашего оператора связи или маршрутизатора, это утечка DNS.
- Откройте chrome://webrtc-internals. Ввод этого адреса в адресную строку Chrome отобразит текущие соединения WebRTC и адреса-кандидаты. Элемент появится, если у вас открыта тестовая страница WebRTC или страница видеозвонка в другой вкладке.
- Проверьте IP-адрес кандидата. Если адрес кандидата srflx (отражение сервера) совпадает с исходным общедоступным IP-адресом из шага 1, то это утечка WebRTC. Если это IP-адрес VPN-сервера или видны только имя .local и частный IP-адрес, общедоступный IP-адрес не отображается.
- Проверьте IPv6. Если на шаге 1 у вас был адрес IPv6, включите VPN и посмотрите, исчез ли или изменился ли этот адрес. В этом случае IPv6 покидает туннель. Переключитесь между Wi-Fi и мобильными данными и повторите действия, чтобы проверить, совпадают ли результаты после перезапуска браузера.
| Результаты наблюдения | значение | Следующая причина |
|---|---|---|
| IP-адрес VPN-сервера виден на сайте | Веб-коммуникации проходят через путь VPN | Нормально, следующий шаг |
| IPv4 изменился, но IPv6 — это исходный адрес. | IPv6 покидает туннель | Причина 2 |
| DNS-сервер принадлежит телекоммуникационной компании или маршрутизатору. | утечка DNS | Причины 1, 3, 4, 5 |
| DNS-сервер является общедоступным DNS-провайдером. | DNS в вашей конфигурации VPN или безопасный DNS, который вы указываете самостоятельно. | Не думайте, что это утечка, основываясь только на названии компании, проверьте причину 4. |
| Исходный публичный IP-адрес виден в WebRTC. | Утечка WebRTC | Причины 6 и 7 |
| В WebRTC видны только локальные имена или частные IP-адреса. | Публичный IP-адрес не раскрывается | в целом нормально |
| Исходный IP только сразу после переключения сети | разрыв в момент перехода | Причина 8 |
Результаты могут различаться в зависимости от места тестирования. Есть места, где просматривается только IPv4, и места, где просматривается IPv6, и методы поиска DNS-серверов также различаются. Сравнивайте в нескольких местах и переключаясь на несколько сетей.
Что показывает DNS-запрос?
DNS-запросы содержат имена доменов. Содержимое страницы или введенные значения не учитываются. DNS — это система адресной книги Интернета, которая преобразует доменные имена, читаемые людьми, в IP-адреса, используемые компьютерами. Каждый раз, когда вы вводите адрес в браузере или приложение связывается с сервером, ваше устройство сначала запрашивает DNS-сервер: «Каков адрес этого имени?» Таким образом, просто просматривая историю запросов, вы можете многое узнать о том, когда и к какому сервису вы пытались получить доступ.
- мое устройствоПриложение/Браузер
- Обычные текстовые DNS-запросы
- Общественный Wi-Fiкафе роутер
- Обычные текстовые DNS-запросы
- DNS оператора связисуществующий сервер
- Области, которые могут быть подвержены воздействию
- мое устройствоПриложение/Браузер
- DNS в туннеле
- Общественный Wi-Fiкафе роутер
- DNS в туннеле
- VPN-серверStageVPN
- Запрос по IP VPN-сервера
- DNS-серверУкажите в конфигурации VPN
- VPN-шифрование
Традиционные DNS-запросы передаются на порт UDP 53 в незашифрованном виде. Чтобы компенсировать это, были созданы DoH (RFC 8484), который оборачивает запросы в HTTPS, и DoT (RFC 7858), который оборачивает запросы в TLS. Однако даже если вы используете зашифрованный DNS, имя сервера (SNI), отправленное при подключении к сайту через HTTPS, может быть видно в сети, если сайт и браузер не поддерживают ECH (Encrypted Client Hello).
| способ доставки | Наблюдатель на том же Wi-Fi | Оператор Wi-Fi/компания связи | DNS-сервер, получающий запрос |
|---|---|---|---|
| Обычный DNS (открытый текст) | могу видеть | могу видеть | Виден, с моим общедоступным IP-адресом |
| DoH/DoT (зашифрованный DNS) | не вижу | Не видно, адреса DNS-серверов видны | Виден, с моим общедоступным IP-адресом |
| DNS внутри VPN-туннеля | не вижу | Не видно, видит только, что общается с VPN-сервером | Видимый, с IP-адресом VPN-сервера |
| Статус утечки DNS | Если это обычный текст, вы можете его увидеть. | могу видеть | Виден, с моим общедоступным IP-адресом |
Secure DNS (DoH) и VPN преследуют разные цели. DoH шифрует только DNS-запросы; сам доступ к сайту и IP-адреса, которые видит сайт, остаются прежними. VPN шифрует весь обмен данными между вашим устройством или браузером и VPN-сервером и меняет IP-адрес, который видят сайты. Режим инкогнито также не предотвращает утечки. Режим инкогнито — это функция, которая не оставляет на устройстве историю и файлы cookie, а также не меняет DNS-запросы или маршруты WebRTC.
Как WebRTC определяет IP-адрес?
WebRTC находит собственный адрес несколькими способами для соединения двух устройств по кратчайшему пути и передает результаты скрипту на веб-странице. WebRTC — это технология веб-стандарта, которая позволяет совершать видеозвонки, голосовые вызовы и передавать файлы без плагинов в браузере. Процесс сбора адресов называется ICE (RFC 8445). Даже страницы, которые не совершают видеозвонки, могут запустить этот процесс с помощью скрипта.
- Создать объект подключенияСкрипт веб-страницы создает RTCPeerConnection.
- Соберите местных кандидатовВаш браузер собирает адреса сетевых устройств вашего устройства.
- STUN-запросСпросите сервер STUN «как выглядит мой адрес» с помощью UDP
- Доставка кандидатаНа страницу доставляется список кандидатов, включая публичные адреса, предоставленные сервером STUN.
| Тип кандидата | что-нибудь | Информация, которая может быть раскрыта | Защита последних браузеров |
|---|---|---|---|
| хозяин | Адрес сетевого устройства аппарата | Частный IP (192.168.x и т. д.) | Замаскировано случайным локальным именем (mDNS), но его можно увидеть на сайтах, которым предоставлены разрешения для камеры и микрофона. |
| srflx (отражение сервера) | Мой публичный адрес, видимый сервером STUN | Публичный IP, реальный IP, если вы обходите прокси | Может быть ограничено политикой обработки IP-адресов WebRTC. |
| реле | TURN Адрес сервера ретрансляции | IP-адрес сервера ретрансляции | Если вы используете ретрансляцию, собеседник увидит адрес сервера вместо вашего IP. |
Проблема заключается в запросе STUN на шаге 3. Прокси браузера пересылает веб-запросы, но UDP-коммуникации WebRTC не проходят через прокси в настройках браузера по умолчанию. Таким образом, адрес, предоставленный STUN-сервером, — это не прокси-сервер, а мой исходный общедоступный IP-адрес. С VPN для всего устройства дела обстоят иначе. Поскольку все соединения UDP, включая запросы STUN, передаются в туннель, адрес, видимый сервером STUN, также является IP-адресом сервера VPN.
Прокси-сервер браузера и политика по умолчанию
- Веб-запросы проходят через прокси
- Запросы STUN передаются непосредственно в UDP.
- Страница может видеть реальный общедоступный IP-адрес.
Прокси браузера и Disable_non_proxied_udp
- Запретить UDP проходить через прокси
- WebRTC использует только прокси-пути
- Некоторые вызовы имеют разные способы соединения или качество соединения.
VPN на уровне устройства
- Запросы STUN также проходят через туннель.
- Кандидатом публичного адреса является IP-адрес VPN-сервера.
- Отключение и обработка IPv6 требуют подтверждения.
В Chrome есть «политика обработки IP-адресов WebRTC», которая определяет, какой адрес будет использовать WebRTC, и расширения могут изменить это значение. Каждое значение соответствует четырем методам, описанным в Рекомендации IETF по обработке IP-адресов WebRTC (RFC 8828).
| политическая ценность | движение | диапазон воздействия |
|---|---|---|
| по умолчанию | Собирайте кандидатов со всех сетевых устройств | Самый широкий (локальные адреса, замаскированные mDNS) |
| default_public_and_private_interfaces | Используйте только устройства по маршруту по умолчанию, используйте как общедоступные, так и частные адреса. | Не раскрывает адреса других устройств |
| default_public_interface_only | Используйте только публичные адреса маршрута по умолчанию. | Частные адреса не раскрываются |
| отключить_non_proxied_udp | Нет UDP через прокси, используйте TCP через прокси, если прокси не поддерживает UDP | Не раскрывайте адреса маршрутов за пределами прокси |
Решение: Как проверить и устранить причину
Большинство утечек имеют одну из восьми причин: Обычно это происходит из-за перекрытия настроек. Начните с проверки номера причины, указанного в таблице диагностики, и каждый раз, когда вы его устраняете, повторяйте шаг 6, показанный на рисунке выше, чтобы увидеть, изменился ли результат. Если вы измените несколько настроек одновременно, вы не узнаете, что сработало.
Причина 1 · В конфигурации VPN отсутствует DNS-сервер или устройство использует другой DNS.
проверять При включенном VPN тест DNS показывает маршрутизатор Wi-Fi или DNS-сервер оператора связи. В настройках Wi-Fi вашего устройства часто используется ручной DNS.
решать Приложение StageVPN включает DNS-сервер в конфигурацию VPN и отправляет запросы в туннель. В настройках сети вашего устройства измените ручной DNS на автоматический, затем отключитесь и снова подключитесь к VPN. Если проблема осталась прежней, проверьте причины 3 и 5.
Причина 2 IPv6 выходит за пределы туннеля
проверять IPv4 был изменен на адрес VPN-сервера, но IPv6 остался таким же, как значение, записанное на шаге 1. Если VPN туннелирует только IPv4, запросы и соединения IPv6 будут идти по исходному маршруту.
решать Приложение StageVPN также настроено на отправку IPv6-соединений в туннель (AllowedIPs 0.0.0.0/0, ::/0), поэтому обычно нет необходимости его отключать. Если IPv6 по-прежнему отображается должным образом, сначала проверьте, не меняет ли маршрут другое VPN-приложение или настройки устройства. Некоторые тестовые сайты не поддерживают IPv6, поэтому сравните более чем на одном сайте.
Причина 3 · Операционная система одновременно запрашивает DNS нескольких сетевых устройств.
проверять Тест DNS показывает как DNS VPN, так и DNS вашего оператора связи, особенно во время VPN-подключения на ПК с Windows. Это вызвано функцией, которая запрашивает все сетевые устройства одновременно, например интеллектуальным разрешением многодоменных имен Windows.
решать Постоянно обновляйте свою операционную систему и программное обеспечение VPN и повторяйте тестирование. Это явление в основном наблюдается в VPN на уровне устройства на ПК и не происходит одинаково в приложении StageVPN на смартфонах и StageVPN для Chrome в Chrome из-за различных структур.
Причина 4 · Безопасный DNS (DoH) указан отдельно в браузере или на устройстве.
проверять Тест DNS показывает серверы общедоступных DNS-провайдеров. В этом случае это может быть не утечка, а настройка, которую вы указали сами. Если у вас есть VPN на уровне устройства, этот запрос также будет проходить через туннель, но он будет получен указанным провайдером, а не DNS в вашей конфигурации VPN.
решать Если это предполагаемая настройка, вы можете оставить ее как есть. Если вы хотите использовать DNS для конфигурации VPN, настройки безопасного DNS автоматически изменятся в вашем браузере и на устройстве. Важно не предполагать, что это утечка, просто взглянув на название компании.
Причина 5 · Другие приложения VPN, прокси и безопасности также включены.
проверять Одновременно включаются сетевые функции других VPN-приложений, расширений прокси, рекламных фильтров или программ безопасности. Настройки маршрута перезаписывают друг друга, в результате чего некоторые запросы переходят к исходному маршруту.
решать Включайте только по одному. Выключите другие приложения и расширения, отключите и снова подключите StageVPN и повторите шаг 6. Настройки прокси-сервера Chrome могут управлять только одним расширением одновременно, поэтому, если другое расширение использует прокси-сервер, StageVPN для Chrome не будет подключаться и сообщит вам, почему.
Причина 6 · Используется только прокси-сервер браузера, но ожидается связь за пределами браузера.
проверять Я включил StageVPN для Chrome, но другие браузеры, мессенджеры и почтовые программы для ПК подключаются, используя исходный IP и исходный DNS. Это не утечка, это расчетный диапазон. Расширение распространяется только на общение в Chrome.
решать Если вам необходимо защитить программы за пределами Chrome, используйте VPN, применимую ко всему устройству. На смартфонах именно это делает приложение StageVPN. Разница в области применения этих двух методов заключается в Браузерный VPN против App VPNЯ организовал это в формате .
Причина 7. Политика WebRTC не применена.
проверять Я включил StageVPN для Chrome и вижу исходный общедоступный IP-адрес в тесте WebRTC или в кандидате srflx в chrome://webrtc-internals. Если другое расширение или политика управления компании/организации сначала контролирует настройки WebRTC, StageVPN для Chrome не изменит политику и оставит ее как есть.
решать Отключите все другие расширения, управляющие настройками WebRTC, и повторно подключите StageVPN для Chrome. Если причиной является политика управления, обратитесь к администратору. Чтобы писать в окне инкогнито, необходимо включить «Разрешить в режиме инкогнито» на экране управления расширениями. Если этот параметр отключен, связь в Windows в режиме инкогнито не осуществляется через прокси-сервер.
Причина 8 · Момент потери VPN-соединения
проверять Исходный IP виден только сразу после переключения сетей или выхода из спящего режима, а через некоторое время нормально. Во время отключения все запросы и сообщения передаются по обычному маршруту.
решать Прежде чем выполнять какую-либо конфиденциальную работу, проверьте, включен ли индикатор завершения подключения приложения или значок расширения. WireGuard, используемый приложением StageVPN, не восстанавливает туннель даже при переходе с Wi-Fi на LTE, но протокол не может компенсировать временные отключения в самой сети. Возможность автоматической блокировки соединений при отключении VPN не является функцией StageVPN. Принцип заключается в том, Объяснение принципов WireGuardЭто в
Как приложения StageVPN и StageVPN для Chrome предотвращают утечки?
Приложение StageVPN снижает утечку данных за счет туннелирования всех соединений, а StageVPN для Chrome выполняет поиск имен прокси-серверов и корректирует политики WebRTC. Поскольку объем защиты различен, способы ее реализации также различаются.
| элемент | Приложение StageVPN (iPhone·iPad·Android) | StageVPN для Chrome |
|---|---|---|
| диапазон защиты | Все устройства | Браузер Chrome |
| Сообщения, отправленные через VPN-маршрут | IPv4·IPv6 Все (разрешенные IP-адреса 0.0.0.0/0, ::/0) | Веб-запросы проходят через прокси (за исключением частных IP-диапазонов и локального хоста). |
| DNS-запросы | Переадресация внутри туннеля на DNS-сервер, указанный в конфигурации VPN. | Запросы, проходящие через прокси, просматриваются не Chrome, а прокси-сервером. |
| ВебRTC | Вся связь UDP проходит через туннель. | Disable_non_proxied_udp применяется во время подключения и возвращается к исходным настройкам при отключении. |
| Что вы сейчас видите в сети | Тот факт, что существует зашифрованная связь с VPN-сервером и объем данных | Поиск по имени адресов прокси-серверов, зашифрованные соединения с прокси-сервером и связь с приложениями за пределами Chrome. |
| Случаи, которые могут не применяться | Хотя VPN-соединение потеряно, когда другое VPN-приложение перенаправляет | Окно инкогнито с отключенным режимом «Разрешить инкогнито», когда другое расширение или политика управления контролируют настройки прокси/WebRTC. |
| История доступа (93 дня) | Просматриваемые домены не записываются | Имя подключенного хоста назначения записывается, но путь или условие поиска не записываются. |
StageVPN не предлагает вам отдельное меню настроек защиты от утечки DNS как функцию своих предложений. Вышеописанное поведение зависит от конфигурации VPN приложения по умолчанию и метода подключения расширения. Объем предоставления составляет Особенности и объем предложенияВы можете проверить это здесь.
Отсутствие утечек означает, что запросы и сообщения проходят через VPN-канал, а не через оператора связи. Это не означает, что записи не будут вестись. StageVPN хранит записи о доступе в течение 93 дней в соответствии с Законом о защите тайны связи и не записывает содержимое сообщений. Товар Уведомление о доступе к хранилищу записейНу, причина, по которой я это раскрываю, в том, что Почему мы раскрываем нашу политику хранения записей доступа?объяснил.
Контрольный список для перепроверки: Что вы перепроверяете после внесения изменений?
Каждый раз, когда вы устраняете одну причину, снова проверьте приведенные ниже пункты с самого начала. Если все прошло, то утечки нет. Если какой-либо элемент выходит из строя, он возвращается на соответствующую карту причины.
- После отключения и повторного подключения VPN я проверил, показывает ли приложение завершение подключения или значок расширения показывает ВКЛ.
- На странице проверки IP вы либо увидите адрес VPN-сервера как для IPv4, так и для IPv6, либо не увидите IPv6.
- Тест DNS не показывает DNS-сервер телекоммуникационной компании или маршрутизатора.
- Кандидат srflx в chrome://webrtc-internals не имеет исходного общедоступного IP-адреса.
- Сетевые функции других VPN-приложений, прокси/расширений VPN и программ безопасности отключены.
- Если вы установили ручной DNS или безопасный DNS для вашего устройства и браузера, вы убедились, что это предполагаемая настройка.
- Ваша операционная система, браузер, приложения и расширения StageVPN обновлены.
- Тот же результат даже после переключения между Wi-Fi и мобильными данными и перезапуска браузера.
- Если вам нужно защитить программы за пределами Chrome, вы можете использовать VPN для всего устройства, а не расширение.
Также полезно определить, когда необходима повторная проверка. Это происходит после серьезного обновления вашей операционной системы или браузера, после установки нового расширения или приложения безопасности или перед выполнением какой-либо конфиденциальной работы в сети, к которой вы подключаетесь в первый раз. Если настройки те же, но результаты изменились, причиной обычно является одна из этих трех причин. Как только вы освоитесь, 6 этапов диагностики можно будет пройти всего за несколько минут.
Если проблема не устранена, укажите модель устройства, версию операционной системы и приложения, время возникновения и результаты тестирования. поддержка клиентовПожалуйста, свяжитесь с нами. Пожалуйста, не отправляйте свой пароль или код подтверждения. Настройки устройства, которые необходимо проверить вместе с проверкой на утечки: 10 настроек конфиденциальности смартфонаЧто ж, существуют риски, которые невозможно решить с помощью только VPN. Что VPN предотвращают и не могут предотвратитьНу, твои привычки в общедоступных сетях Правила безопасности общественного Wi-FiЯ организовал это в формате .
справочный материал
- RFC 1034: Доменные имена — концепции и возможности — Структура DNS и роль преобразователей (IETF)
- RFC 8484: DNS-запросы через HTTPS (DoH) — Как шифровать DNS-запросы через HTTPS (IETF)
- RFC 7858: DNS через TLS — Как шифровать DNS-запросы с помощью TLS (IETF)
- RFC 8445: Установление интерактивного соединения (ICE) — Типы кандидатов на соединение WebRTC и процедуры сбора данных (IETF)
- RFC 8828: Требования к обработке IP-адресов WebRTC — Диапазон адресов, которые браузеры предоставляют WebRTC (IETF).
- API chrome.privacy — Значения политики обработки IP-адресов Chrome WebRTC (Chrome для разработчиков)
- API хром.прокси — Настройки прокси-сервера расширения, список обхода и приоритеты управления (Chrome для разработчиков)
- ВебRTC API — RTCPeerConnection и концепция кандидатов ICE (Веб-документы MDN)
