- Обнаружение утечки WebRTC при использовании SOCKS5: как маскировать локальный IP в браузере

Обнаружение утечки WebRTC при использовании SOCKS5

SOCKS5 проксирует HTTP и HTTPS. WebRTC это игнорирует. Протокол устроен так, что браузер сам ищет кратчайший путь к пиру, используя STUN. SOCKS5 тут не помощник — WebRTC работает напрямую через UDP, а SOCKS5 создан для TCP.

Локальный IP улетает наружу за миллисекунды. Даже если весь трафик завёрнут в прокси, WebRTC-соединение строит прямой канал. Проверяется это просто, лечится сложнее.

Почему SOCKS5 не спасает

SOCKS5 — это посредник для TCP-сессий. Браузер устанавливает соединение с прокси, прокси — с целевым сервером. WebRTC использует UDP и ICE-кандидатов. Протокол ICE собирает все доступные адреса: локальные, публичные через STUN, релейные через TURN. SOCKS5 в этом списке нет.

Пример утечки: браузер с SOCKS5-прокси на 127.0.0.1:9050 открывает сайт, который запускает WebRTC-клиент. Сайт получает реальный IP пользователя через STUN-запрос, который идёт мимо прокси. Прокси тут — декорация.

Причина — архитектурная. WebRTC не смотрит на системные настройки прокси. Он работает на уровне сокетов, а не HTTP. Поэтому любые browser-based решения с SOCKS5 дают течь.

Как проверить утечку

Откройте browserleaks.com/webrtc или ip.lexic.ml/webrtc. Эти сервисы запускают STUN-запрос к Google-серверам и показывают ваш публичный IP. Если видите адрес, отличный от IP прокси — утечка.

Быстрая проверка через консоль браузера:

```javascript

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));

```

В выводе ищите `srflx` — это публичный IP, полученный через STUN. Если он совпадает с IP прокси — всё чисто. Если нет — утечка.

Маскировка через расширения браузера

Расширения типа WebRTC Leak Prevent перехватывают вызовы `RTCPeerConnection` и модифицируют ICE-кандидаты. Они подменяют `srflx`-кандидаты на адрес прокси или отключают их вовсе.

Работает это так: расширение внедряет скрипт в каждую страницу, который патчит нативный `RTCPeerConnection`. Вместо реальных кандидатов подставляются пустые или проксированные. Минус — расширение видно в трафике, некоторые сайты это детектят.

Настройка для Firefox:

```javascript

// about:config

media.peerconnection.enabled = false; // полное отключение

media.peerconnection.ice.default_address_only = true; // только серверные кандидаты

```

Полное отключение WebRTC ломает видеочаты. Компромисс — `ice.default_address_only`, который скрывает локальные адреса, но оставляет публичные. Правда, публичный IP всё равно утекает.

Отключение WebRTC через политики

Chrome и Firefox позволяют управлять WebRTC через групповые политики. В Chrome это `WebRtcIpHandlingPolicy`:

```json

{

"WebRtcIpHandlingPolicy": "disable_non_proxied_udp"

}

```

Политика `disable_non_proxied_udp` заставляет WebRTC использовать только проксированные UDP-соединения. Если прокси не поддерживает UDP — WebRTC просто не работает. Это жёсткий, но надёжный вариант.

Для Firefox в enterprise-политиках есть параметр `WebRTCDefaultAddressPolicy`:

```json

{

"policies": {

"WebRTCDefaultAddressPolicy": {

"Default": "disable_non_proxied_udp"

}

}

}

```

TURN-сервер как решение

TURN-сервер — это релейный узел для WebRTC. Весь медиа-трафик идёт через него, а не напрямую. Если настроить TURN с обязательной релейной передачей, реальный IP не утечёт.

Минус — задержка. TURN добавляет 30-80 мс к каждому пакету. Для голосовых звонков это терпимо, для игр — критично. TURN-сервер требует ресурсов: на 100 одновременных соединений нужно около 1 Гбит/с канала и 4 ядра CPU.

Пример конфигурации coturn:

```

listening-port=3478

tls-listening-port=5349

realm=example.com

server-name=example.com

fingerprint

lt-cred-mech

user=test:password

total-quota=100

stale-nonce=600

```

Клиентская часть:

```javascript

const pc = new RTCPeerConnection({

iceServers: [

{urls: 'turn:turn.example.com:3478', username: 'test', credential: 'password'},

{urls: 'stun:stun.example.com:3478'}

],

iceTransportPolicy: 'relay'

});

```

`iceTransportPolicy: 'relay'` — ключевой момент. Он запрещает прямые соединения, разрешая только через TURN. IP остаётся скрытым, но каждый звонок жрёт трафик через сервер.

Настройка прокси для WebRTC

SOCKS5 не умеет UDP, но есть прокси, которые умеют. Например, SSH-туннель с UDP-релеем или WireGuard. Но в браузере это не настроить — нужен системный уровень.

Один из вариантов — использовать прокси на уровне сети. Настраиваете WireGuard-туннель на VPS, весь трафик идёт через него. WebRTC работает поверх туннеля, и наружу торчит IP VPS. Прокси-сервер тут не нужен.

Пример конфигурации WireGuard:

```

[Interface]

PrivateKey =

Address = 10.0.0.2/24

DNS = 1.1.1.1

[Peer]

PublicKey =

Endpoint = vps.example.com:51820

AllowedIPs = 0.0.0.0/0

```

Это работает, потому что WireGuard перехватывает весь IP-трафик, включая UDP. WebRTC не может обойти туннель — он работает на уровне IP, а не приложений.

Проверка после настройки

После любых манипуляций проверяйте утечку. Используйте несколько сервисов: browserleaks.com/webrtc, ip.lexic.ml/webrtc, whoer.net. Один сервис может показать чистый результат, другой — найти утечку.

Автоматизированная проверка через Python:

```python

import subprocess

import json

def check_webrtc():

result = subprocess.run(

['curl', '-s', 'https://ip.lexic.ml/webrtc'],

capture_output=True, text=True

)

data = json.loads(result.stdout)

public_ip = data.get('public_ip')

return public_ip

def main():

ip = check_webrtc()

if ip:

print(f"Public IP: {ip}")

else:

print("WebRTC disabled or proxied")

if __name__ == '__main__':

main()

```

Если сервис возвращает IP прокси или не возвращает ничего — утечка закрыта.

Сравнение методов защиты

| Метод | Сложность | Надёжность | Влияние на работу |

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

| Расширение браузера | Низкая | Средняя | Ломает некоторые сайты |

| Отключение WebRTC | Низкая | Высокая | Видеочаты не работают |

| Политики Chrome | Средняя | Высокая | Может ломать звонки |

| TURN-сервер | Высокая | Высокая | Задержка 30-80 мс |

| WireGuard-туннель | Средняя | Высокая | Нет проблем с WebRTC |

Расширения — самый быстрый способ, но они видны сайтам. Политики — надёжнее, но требуют прав администратора. TURN — дорого и медленно. WireGuard — лучший вариант, если нужен полный контроль.

Как устроена утечка на уровне кода

Когда браузер запускает WebRTC, он создаёт ICE-агента. Тот собирает кандидатов: локальные IP из сетевых интерфейсов, публичный IP через STUN, релейные через TURN. SOCKS5 не участвует в этом процессе вообще.

STUN-запрос уходит на сервер типа `stun.l.google.com:19302` напрямую, минуя прокси. Браузер не проверяет системные настройки прокси для WebRTC-трафика. Это особенность архитектуры, а не баг.

Ответ STUN содержит публичный IP и порт. Браузер добавляет его в список кандидатов и отправляет пиру через сигнальный канал. Пир видит реальный IP. Прокси остаётся в стороне.

Реальный пример утечки

Пользователь настроил Firefox на SOCKS5 через 127.0.0.1:9050 (Tor). Открыл сайт с видеочатом. Через 2 секунды сайт получил реальный IP пользователя через STUN. Прокси не помог, потому что WebRTC работает в обход.

Решение — отключить WebRTC в about:config. Пользователь потерял возможность звонить, но IP перестал утекать. Альтернатива — настроить TURN-сервер и заставить браузер использовать только relay-кандидатов.

Практические шаги для защиты

Для начала определитесь, нужен ли WebRTC. Если нет — отключите его полностью. В Chrome это делается через политику или расширение, в Firefox — через about:config.

Если WebRTC нужен — настройте TURN-сервер и используйте `iceTransportPolicy: 'relay'`. Это гарантирует, что реальный IP не утечёт, но добавит задержку.

Для полной анонимности используйте WireGuard или OpenVPN на системном уровне. Тогда WebRTC работает внутри туннеля, и наружу виден только IP VPN-сервера. SOCKS5 для этой задачи не подходит.