Почему ваш прокси "светится": анализ WebRTC-утечек и DNS-запросов через IPv6

Анатомия утечки: как браузер обходит прокси

Вы настроили прокси, проверили IP на сайте — всё чисто. Но через минуту ваш реальный адрес уже в логах. Классика. Браузеры — это зоопарк технологий, и каждая тянет соединения по-своему.

WebRTC — главный виновник. Этот протокол для видеозвонков и файлообмена работает напрямую, игнорируя системные настройки прокси. Он использует STUN-серверы, чтобы узнать свой внешний IP. И вот тут начинается веселье: браузер отправляет запрос на STUN-сервер через ваш реальный сетевой интерфейс, а не через прокси.

```javascript

// Проверка WebRTC-утечки прямо в консоли браузера

const pc = new RTCPeerConnection({

iceServers: [{ urls: "stun:stun.l.google.com:19302" }]

});

pc.createDataChannel("test");

pc.onicecandidate = e => {

if (e.candidate) {

console.log(e.candidate.candidate);

}

};

pc.createOffer().then(o => pc.setLocalDescription(o));

```

Запустите этот код на странице с включённым прокси. Если увидите IP, который не совпадает с адресом прокси — всё, вы светитесь. Это работает даже в приватном режиме.

IPv6: невидимый канал утечки

IPv6 — отдельная песня. Многие прокси-серверы работают только на IPv4. Браузер получает IPv6-адрес от вашего провайдера и использует его для прямых соединений, даже когда прокси включён. Выглядит это так: основной трафик идёт через прокси на IPv4, а WebRTC или даже обычные HTTPS-запросы летят напрямую через IPv6.

Проверка простая:

```bash

curl -6 https://api6.ipify.org

```

Если команда вернула IP, отличный от адреса вашего прокси, — канал открыт. Большинство VPN-клиентов и браузерных расширений не блокируют IPv6-трафик. Они просто про него забывают.

DNS-запросы: тихий информатор

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

Проверить просто. Смотрим, какой DNS-сервер используется:

```bash

cat /etc/resolv.conf

```

Или на Windows:

```powershell

nslookup example.com

```

Если в ответе виден адрес вашего провайдера (обычно что-то вроде 192.168.0.1 или 10.0.0.1) — ваш DNS-трафик не зашифрован и не проходит через прокси. Даже если сам прокси работает идеально, DNS-запросы выдают вас с головой.

Как IPv6-прокси решают проблему

Тут в игру вступают сервисы вроде lexic.ml. Их особенность — полная поддержка IPv6 на всех уровнях. Это значит, что и HTTP, и SOCKS5, и DNS-запросы идут через прокси-инфраструктуру, которая работает на обеих версиях протокола.

Когда ваш браузер пытается установить WebRTC-соединение через IPv6, он упирается в прокси-сервер, который обрабатывает и IPv6-трафик. Реального адреса в STUN-ответе нет — только адрес прокси. DNS-запросы тоже уходят через зашифрованный туннель, а не напрямую к провайдеру.

Техническая реализация: почему это работает

Разберём на примере. Стандартный прокси на IPv4 обрабатывает только входящие соединения по протоколу IPv4. IPv6-трафик либо отбрасывается, либо идёт в обход. Браузер Chrome, например, при включённом прокси для IPv4 продолжает использовать IPv6 для прямых соединений — это поведение зашито в коде.

IPv6-прокси решают проблему на уровне маршрутизации. Весь трафик — и IPv4, и IPv6 — заворачивается в туннель. Браузер видит только адрес прокси. WebRTC-кандидаты содержат только адреса прокси-серверов, а DNS-запросы уходят через зашифрованный канал.

```bash

Проверка полной маршрутизации через прокси

curl --socks5-hostname proxy.example.com:1080 https://api.ipify.org

curl -6 --socks5-hostname proxy.example.com:1080 https://api6.ipify.org

```

Обе команды должны вернуть IP-адрес прокси. Если вторая вернула ваш реальный IPv6 — прокси не поддерживает IPv6.

Кейс: Chrome и WebRTC через IPv4-прокси

Пример: сервер на nginx 1.24 с прокси-настройками для IPv4. Браузер Chrome 120. Включаем прокси в настройках системы. Открываем сайт с WebRTC-функционалом. Через 30 секунд в консоли видим:

```

candidate:1 1 UDP 2122260223 192.168.1.37 53142 typ host

candidate:1 1 UDP 2122260222 203.0.113.5 53143 typ srflx

```

Первый кандидат — локальный IP (192.168.1.37), второй — реальный внешний (203.0.113.5). Ни один не совпадает с адресом прокси. Утечка полная. Причина: WebRTC использует системные сетевые интерфейсы напрямую, игнорируя настройки прокси в браузере.

Решение — отключить WebRTC в настройках Chrome или использовать прокси с поддержкой WebRTC-перехвата. Такие прокси подменяют STUN-ответы, подставляя свои адреса. Работает это на уровне сетевого стека, поэтому браузер не может обойти перехват.

Кейс: DNS-утечка при работающем прокси

Ситуация: пользователь настроил SOCKS5-прокси в Firefox. IP-адрес проверен — всё сходится. Но провайдер присылает письмо о подозрительной активности. Выясняется: DNS-запросы уходили напрямую к DNS-серверу провайдера (192.168.1.1), а не через прокси.

Причина: Firefox по умолчанию использует системный DNS, который не маршрутизируется через SOCKS5. Решение — включить в Firefox параметр `network.proxy.socks_remote_dns` в значении `true`. После этого DNS-запросы пойдут через прокси.

```javascript

// Настройка Firefox для DNS через прокси

// about:config → network.proxy.socks_remote_dns → true

```

Но это работает только для Firefox. Chrome и Safari не имеют такой настройки. Для них нужен прокси, который перехватывает DNS-запросы на сетевом уровне.

Кейс: IPv6-утечка при включённом VPN

Пользователь подключил VPN-клиент на OpenVPN 2.6. Проверка IPv4 показала адрес VPN-сервера. Но через 10 минут работы сервис аналитики зафиксировал реальный IPv6-адрес пользователя.

Причина: OpenVPN по умолчанию не блокирует IPv6-трафик. Весь IPv6-трафик шёл напрямую через сетевой интерфейс провайдера. Решение — добавить в конфигурацию OpenVPN блокировку IPv6:

```

Блокировка IPv6 в конфигурации OpenVPN

pull-filter ignore "route-ipv6"

pull-filter ignore "ifconfig-ipv6"

```

Или использовать прокси с полной поддержкой IPv6, который маршрутизирует оба протокола через один туннель.

Практические проверки: что делать прямо сейчас

Проверьте свой прокси на утечки. Три теста за пять минут:

1. Откройте `https://browserleaks.com/webrtc` — покажет все кандидаты WebRTC.

2. Выполните `curl -6 https://api6.ipify.org` — покажет IPv6-адрес.

3. Используйте `https://dnsleaktest.com` — покажет DNS-серверы, которые видят ваши запросы.

Если хотя бы один тест показал ваш реальный IP или DNS-сервер провайдера — у вас утечка. Прокси работает только наполовину.

Настройка браузеров: закрываем дыры

Для Chrome и Firefox есть расширения, блокирующие WebRTC. Но они работают на уровне JavaScript — часть кандидатов всё равно утекает. Надёжнее отключить WebRTC через политики:

```bash

Отключение WebRTC в Chrome через групповые политики

Windows: реестр

reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v WebRTCIPHandlingPolicy /t REG_SZ /d "disable_non_proxied_udp" /f

```

Параметр `disable_non_proxied_udp` запрещает WebRTC использовать UDP-соединения, которые не идут через прокси. Но это ломает работу видеозвонков — они требуют UDP.

Как выбирать прокси: чек-лист

Критерии выбора прокси, который не светится:

| Критерий | Что проверять |

|----------|---------------|

| Поддержка IPv6 | Прокси-сервер должен иметь IPv6-адрес и маршрутизировать IPv6-трафик |

| DNS-маршрутизация | DNS-запросы должны идти через прокси, а не через системный DNS |

| WebRTC-перехват | Прокси должен подменять STUN-ответы и блокировать прямые кандидаты |

| Протоколы | SOCKS5 с поддержкой удалённого DNS, HTTP с CONNECT-методом |

Проверяйте не только скорость, но и эти параметры. Скорость бесполезна, если ваш реальный IP виден каждому сайту.

Что в итоге

Утечки через WebRTC, IPv6 и DNS — не баги, а особенности архитектуры. Браузеры и операционные системы так устроены. Прокси, который не учитывает эти особенности, — просто игрушка.

Настройте прокси правильно. Проверьте все три канала утечки. Если ваш прокси не поддерживает IPv6 и не маршрутизирует DNS — он не решает проблему приватности.