---
description: Принцип роботи WebRTC
icon: wave-square
---

# Як виникає витік через WebRTC

Антифрод-система не отримує вашу реальну IP-адресу окремим запитом. Вона **порівнює дві адреси**: адресу TCP-сесії та адресу, яку браузер повідомляє через WebRTC поверх UDP. Розбіжність між ними стає сигналом.

### Механіка перевірки

Послідовність однакова для всіх трьох сценаріїв:

1. Браузер відкриває сторінку через SOCKS5-проксі. Увесь HTTP/HTTPS-трафік передається через TCP, тому сайт бачить IP-адресу проксі.
2. Антифрод-система передає сторінці скрипт, який створює `RTCPeerConnection` і вказує власний STUN- або TURN-сервер у `iceServers`.
3. Браузер починає збирати ICE-кандидатів і надсилає на цей сервер **STUN Binding Request через UDP**.
4. STUN-сервер повертає `Binding Response` з атрибутом `XOR-MAPPED-ADDRESS`. У ньому вказана публічна адреса джерела пакета. Браузер перетворює її на **srflx-кандидата**.
5. Скрипт отримує кандидата через `onicecandidate`, дістає з нього IP-адресу та порівнює її з адресою TCP-сесії.

Ключовий момент: **крок 3**. Чи пройде UDP-пакет через проксі, залежить від двох умов: чи підтримує проксі UDP і чи вміє браузер спрямовувати UDP через цей проксі. Звідси виникають три можливі результати.

<br>

<figure>
  <picture>
    <source srcset="../../.gitbook/assets/webrtc-leak_black.svg" media="(prefers-color-scheme: dark)">
    <img src="../../.gitbook/assets/webrtc-leak_white.svg" alt="Сценарії роботи WebRTC через проксі">
  </picture>
</figure>

### Сценарій 1. Проксі передає UDP, адреси збігаються

1. TCP-сесія проходить через SOCKS5-проксі, тому сайт бачить `198.51.100.7`.
2. Антифрод-система передає скрипт із налаштуваннями свого STUN-сервера.
3. Браузер відкриває UDP-асоціацію через той самий проксі (`UDP ASSOCIATE`, RFC 1928) і надсилає Binding Request через нього.
4. STUN бачить адресу проксі та повертає те саме значення в `XOR-MAPPED-ADDRESS`: `198.51.100.7`.
5. Скрипт порівнює значення. IP-адреса TCP-сесії та srflx-кандидат збігаються.

**Результат:** WebRTC працює штатно, кандидати доступні, а адреси збігаються. На мережевому рівні профіль поводиться як звичайний користувач.

Для цього одночасно потрібні дві умови: проксі з підтримкою `UDP ASSOCIATE` і клієнт, наприклад браузер або антидетект-браузер, який справді спрямовує WebRTC-трафік через проксі.

***

### Сценарій 2. UDP обходить проксі та розкриває реальну адресу

1. TCP-сесія проходить через проксі, тому сайт бачить `198.51.100.7`.
2. Антифрод-система передає скрипт із налаштуваннями свого STUN-сервера.
3. Браузер надсилає Binding Request **безпосередньо з мережевого інтерфейсу**, оминаючи проксі.
4. STUN бачить реальну адресу `113.22.13.2` і повертає її як srflx-кандидата.
5. Скрипт порівнює значення: `113.22.13.2` ≠ `198.51.100.7`. Проксі виявлено, реальну IP-адресу розкрито.

**Результат:** витік IP-адреси. Антифрод-система отримує конкретну адресу, а не лише підозрілу ознаку.

UDP може обходити проксі з кількох причин:

* проксі підтримує **лише TCP**: HTTP-проксі через `CONNECT` передає тільки TCP, як і SOCKS5 без `UDP ASSOCIATE`;
* проксі підтримує UDP, але **браузер не спрямовує UDP через нього**: Chrome за замовчуванням не передає WebRTC-трафік через налаштований проксі та надсилає його безпосередньо;
* проксі налаштований лише для конкретного профілю або розширення, а WebRTC працює на рівні всього процесу.

Якщо антифрод-система контролює STUN/TURN-сервер, зазначений у `iceServers`, їй навіть не потрібен крок 5. Вона бачить реальну адресу безпосередньо в адресі джерела вхідного UDP-пакета.

Локальні адреси, наприклад `192.168.*` і `10.*`, тут менш важливі. Починаючи з Chrome 80, host-кандидати передаються як mDNS-імена на зразок `<uuid>.local`, тому отримати дані про локальну мережу через WebRTC стало складніше. У цьому сценарії розкривається саме публічна srflx-адреса.

***

### Сценарій 3. Браузер блокує WebRTC: витоку немає, але це помітно

1. TCP-сесія проходить через проксі, тому сайт бачить `198.51.100.7`.
2. Антифрод-система передає скрипт із налаштуваннями свого STUN-сервера.
3. `RTCPeerConnection` заблокований розширенням, налаштуванням браузера або зміненим API в антидетект-браузері. STUN-запит не надсилається ані через проксі, ані безпосередньо.
4. Відповіді немає. `onicecandidate` не спрацьовує, а збирання кандидатів завершується порожнім списком.
5. Скрипту немає чого порівнювати.

**Результат:** реальна IP-адреса не розкрита. Однак антифрод-система бачить іншу аномалію: сучасну настільну версію Chrome, у якій **WebRTC повністю недоступний**. У більшості звичайних користувачів WebRTC увімкнений, тому порожній список кандидатів може підвищити оцінку ризику, як і будь-яка інша невідповідність заявленого user-agent фактичній поведінці API.

Отже, вимкнення WebRTC замінює витік IP-адреси аномалією відбитка. У деяких випадках це прийнятний компроміс, але не повноцінне рішення.