WebRTC і DNS: чому одного проксі мало

Проксі приховує реальну IP-адресу для HTTP/HTTPS-трафіку браузера. Але в браузера є й інші «способи» показати свій реальний IP. Два з них варто перевіряти окремо: WebRTC і DNS.

WebRTC і DNS — це нормальні частини браузера та мережі. Проблема починається тоді, коли мережеві перевірки показують неузгодженість: сайт відкритий через проксі, але WebRTC або DNS leak-тест указує на інший маршрут.

WebRTC: навіщо він узагалі потрібен

WebRTC використовується для peer-to-peer аудіо- і відеодзвінків, демонстрації екрана та передачі даних між браузерами. Щоб знайти робочий шлях між двома сторонами, WebRTC використовує ICE. MDN описує ICE-кандидати як варіанти мережевого з’єднання, через які клієнти можуть спілкуватися напряму або через проміжний сервер: WebRTC connectivity. Сам ICE описаний у RFC 8445.

Саме тут з’являється ризик деанонімізації. RFC 8828 прямо каже, що WebRTC може розкривати вебзастосунку більше інформації про локальну мережу, ніж звичайний HTTP-запит. У документі перелічені зрозумілі випадки: додаткові публічні IP за наявності кількох мережевих інтерфейсів, приватні адреси за NAT і обхід класичного application proxy через STUN, якщо прямий доступ до інтернету дозволений.

Простіше кажучи: якщо звичайна сторінка бачить лише IP проксі, то WebRTC за поганої конфігурації може показати реальну IP-адресу.

Як виглядає WebRTC-витік

Сценарій такий: HTTP-трафік іде через проксі, але WebRTC збирає ICE-кандидати іншим маршрутом.

У дослідженні One Leak Will Sink A Ship автор перевіряв браузери та VPN-сервіси і показав, що WebRTC API міг робити IP-адреси доступними для сайту через JavaScript навіть за ввімкненого VPN. Дослідження старе, тому його не варто читати як точний опис усіх сучасних браузерів. Але воно добре пояснює сам клас проблеми: WebRTC живе не зовсім у тому самому шарі, що й звичайний запит сторінки.

Чому не завжди варто просто вимикати WebRTC

Повністю вимкнути WebRTC — найгрубіший варіант. Іноді він підходить, але має свою ціну: ламаються дзвінки, screen sharing, data channels і будь-які перевірки, де сервіс очікує, що WebRTC API працює.

Навіть Chrome не зводить це питання до «увімкнути/вимкнути». У Chrome є політика webRTCIPHandlingPolicy, яка керує тим, як маршрутизується WebRTC-трафік і скільки локальної адресної інформації розкривається сайтам. У документації Chrome Extensions перелічені режими, зокрема disable_non_proxied_udp: chrome.privacy API. У Chrome Enterprise також є окрема політика для WebRTC IP handling: Chrome Enterprise policy.

Висновок простий: нормальна ціль — не зламати WebRTC, а зробити так, щоб він не показував маршрут, який суперечить профілю.

DNS: де може з’явитися нестикування

DNS перетворює доменне ім’я на IP-адресу. Cloudflare коротко пояснює це так: DNS переводить зрозумілі людині домени на кшталт example.com в IP-адреси, з якими працюють машини: What is DNS?.

DNS-витік — це ситуація, коли основний трафік іде через VPN або проксі, а DNS-запити йдуть іншим маршрутом. Mozilla пояснює це на прикладі VPN: DNS-запити можуть виходити за межі захищеного тунелю, якщо VPN налаштований неправильно або не маршрутизує DNS через власну мережу: What is a DNS Leak?.

Із проксі працює та сама логіка: важливо, де саме резолвиться домен. У документації curl добре видно різницю між локальним і віддаленим DNS. socks5:// означає SOCKS5 із локальним резолвом імені, а socks5h:// — SOCKS5 із резолвом імені на стороні проксі: everything curl: Proxies.

Тут важливо бути точними: звичайний сайт не завжди напряму бачить ваш DNS-резолвер. Тому некоректно писати, що «будь-який сайт одразу дізнається ваш DNS». Правильніше сказати так: DNS-витік показує, що мережевий маршрут налаштований не повністю. Це можна зловити через DNS leak-тести, власну інфраструктуру або системи, які контролюють свої домени й мережеві логи.

Що ми перевіряємо в 0detect

Для нас WebRTC і DNS — це частина єдиного мережевого профілю. Якщо профіль працює через проксі, решта мережевих параметрів має бути узгоджена з ним і не створювати конфліктів.

У нашій документації зі створення профілю мережеві налаштування винесені в окремий блок “Соединение”: до профілю можна прикріпити проксі, вибрати проксі зі списку й налаштувати DNS. Для DNS є режим “Настоящий”: якщо профіль працює через проксі, DNS береться відповідно до цього проксі; якщо проксі немає, використовується ваша адреса; за потреби DNS можна вказати вручну: Створення профілю.

У тих самих загальних налаштуваннях профілю є мова, часовий пояс і геолокація. За документацією ці параметри за замовчуванням підбираються з урахуванням зовнішнього IP. Це не прямо про WebRTC, але про ту саму ідею: IP, DNS, часовий пояс, мова й геолокація мають складатися в одну цілісну історію.

Для автоматизації порядок теж важливий. У Local API проксі створюється окремо, прив’язується до профілю через POST /profile/set/proxy, і лише після цього профіль запускається: Робота з proxy. Це зменшує ризик ситуації, коли скрипт уже відкрив браузер, а мережевий профіль ще не відповідає налаштуванням профілю.

Коротко

WebRTC може розкривати більше мережевої інформації, ніж звичайний HTTP-запит. DNS може йти не тим маршрутом, якщо резолв налаштований локально або минає проксі.
Хороший профіль — це не «проксі поверх браузера». Це браузер, у якого мережеві налаштування, відбиток і географія не суперечать одне одному.