Значок подключения горит, сервис показывает другую страну — казалось бы, всё работает. Но часть трафика при этом может уходить в обход туннеля, и провайдер продолжает видеть, какие сайты вы открываете.

Разберём три механизма, из-за которых это происходит.

Утечка DNS

Прежде чем открыть сайт, устройство переводит доменное имя в IP-адрес — отправляет запрос DNS-серверу. Если этот запрос уходит мимо туннеля, происходит любопытная ситуация: сам трафик к сайту зашифрован и идёт через VPN, а вот список доменов, которые вы посещаете, уходит открытым текстом DNS-серверу провайдера.

С точки зрения приватности это обесценивает VPN почти полностью: именно список посещённых сайтов и есть та информация, которую обычно хотят скрыть.

Почему происходит. Система может использовать DNS-серверы, полученные от роутера, а не выданные VPN-подключением. На Windows дополнительно вмешивается механизм параллельных запросов ко всем сетевым интерфейсам сразу — он ускоряет отклик, но отправляет запрос и мимо туннеля.

Как проверить. Откройте сервис проверки DNS (например, dnsleaktest.com) при включённом VPN. В результатах должны быть серверы страны VPN-сервера или самого сервиса. Если видите имя своего провайдера — утечка есть.

Как закрыть:

  • в конфигурации WireGuard должна быть строка DNS = ... с адресом сервера внутри туннеля;
  • в клиенте включите опцию вида «блокировать сторонний DNS» — она есть в большинстве приложений;
  • убедитесь, что в свойствах сетевого адаптера не прописаны вручную публичные DNS вроде 8.8.8.8: такие настройки часто переживают подключение VPN.

Утечка WebRTC

WebRTC — технология прямой связи между браузерами: видеозвонки, голосовые чаты, передача файлов без сервера-посредника. Чтобы установить прямое соединение, браузеру нужно узнать реальные адреса устройства, и он делает это через механизм ICE — в том числе получая локальный и внешний IP.

Проблема в том, что скрипт на странице может запросить эти данные, и браузер отдаст реальный адрес, даже когда VPN включён. Туннель здесь ни при чём: запрос идёт по другому пути, на уровне API браузера.

Как проверить. Сервисы вроде browserleaks.com/webrtc показывают, какие адреса видны странице. При включённом VPN там не должно быть вашего домашнего IP.

Как закрыть:

  • в Firefox: about:config → media.peerconnection.enabled → false (сломает видеозвонки в браузере);
  • в браузерах на Chromium полное отключение недоступно, помогают расширения, ограничивающие WebRTC локальными адресами;
  • радикальный вариант — режим полного туннелирования, когда весь трафик, включая WebRTC, идёт через VPN.

Отметим: если VPN работает в режиме полного туннеля и корректно настроен, WebRTC покажет адрес VPN-сервера. Утечка характерна для прокси-режима, когда через туннель идёт только часть соединений — типичная ситуация для Shadowsocks и клиентов Xray с правилами маршрутизации.

Утечка IPv6

Многие туннели настраиваются только на IPv4. Если провайдер выдаёт и IPv6-адрес, а конфигурация его не учитывает, происходит следующее: сайты с поддержкой IPv6 открываются напрямую, минуя VPN, — операционная система предпочитает IPv6, когда он доступен.

Внешне всё выглядит нормально, но часть ресурсов видит ваш реальный адрес.

Как проверить. Откройте любой сервис определения IP и сравните результат для IPv4 и IPv6 (например, test-ipv6.com). Если IPv6-адрес принадлежит вашему провайдеру — утечка есть.

Как закрыть:

  • в конфигурации WireGuard в AllowedIPs должны быть указаны оба семейства: 0.0.0.0/0, ::/0;
  • либо IPv6 отключается на уровне системы или адаптера — грубее, но надёжно;
  • в готовых клиентах обычно есть переключатель «блокировать IPv6 вне туннеля».

Обрыв соединения: зачем нужен Kill Switch

Отдельный сценарий: VPN отключился сам — сервер перезагрузился, сеть переключилась, приложение упало. Операционная система при этом не прекращает работу, а просто возвращает трафик на обычный маршрут. Приложения продолжают работать, и человек может не заметить, что защита пропала.

Kill Switch блокирует весь сетевой трафик, пока туннель не восстановится. Это стоит небольшого неудобства — при обрыве интернет пропадает целиком, — но исключает незаметный переход на прямое подключение.

В WireGuard то же самое достигается без отдельной функции: если в конфигурации указан AllowedIPs = 0.0.0.0/0, ::/0, маршрут по умолчанию ведёт в туннель, и при его отсутствии трафику просто некуда идти.

Порядок проверки

Пять минут, которые стоит потратить после настройки:

  1. Отключите VPN, запишите свой IP-адрес и DNS-серверы.
  2. Включите VPN.
  3. Проверьте IPv4-адрес — должен смениться.
  4. Проверьте IPv6 — не должен показывать адрес провайдера.
  5. Проверьте DNS — серверы не должны принадлежать провайдеру.
  6. Проверьте WebRTC — реального адреса быть не должно.
  7. Отключите сеть на минуту и посмотрите, блокируется ли трафик при обрыве.

Повторять имеет смысл после обновления системы или клиента: настройки сетевых интерфейсов иногда сбрасываются.

Коротко

Подключённый VPN и защищённый трафик — не одно и то же. Три канала утечки — DNS, WebRTC и IPv6 — работают независимо от протокола и одинаково касаются WireGuard, OpenVPN и прокси-решений. Проверка занимает несколько минут, а без неё можно годами пользоваться туннелем, который решает не ту задачу, ради которой его ставили.