Перевірка на витік WebRTC: як запобігти витокам IP

Працюючий проксі не гарантує захисту всіх підключень браузера. Тест на витік WebRTC допомагає перевірити маршрутизацію, запобігти несподіваному розкриттю IP і зберегти вашу присутність у мережі захищеною та стабільною. Нижче — повний гайд про те, як це зробити.

Що таке WebRTC

WebRTC (Web Real-Time Communication) — відкритий стандарт, який дає змогу браузерам і застосункам обмінюватися аудіо, відео та даними в реальному часі без плагінів. Зазвичай він використовує UDP для зв'язку з низькою затримкою, але підтримує також TCP і підключення через ретранслятори.

Для встановлення з'єднання WebRTC збирає ICE-кандидати (Interactive Connectivity Establishment): можливі мережеві адреси підключення, що містять адресу, порт і транспортний протокол. Саме ці кандидати стають джерелом усіх можливих витоків. 

Чому проксі «протікають» через WebRTC

Витік WebRTC виникає, коли під час визначення параметрів підключення браузер розкриває адресу, яку ваша схема маршрутизації має приховувати. Тест на витік WebRTC допомагає це виявити.

1. Веб-сторінка запускає збір WebRTC-кандидатів.

2. Браузер звертається до STUN-сервера, щоб дізнатися свою публічну адресу.

3. Якщо це з'єднання йде в обхід проксі, STUN бачить адресу вашого інтернет-провайдера.

4. Браузер може передати цю адресу JavaScript-коду сторінки через ICE-кандидат.

Що важливо пам'ятати:

• Налаштування проксі в браузері не обов'язково поширюються на трафік WebRTC.

• Правильно налаштований VPN з повним тунелюванням має пропускати і цей трафік; WebRTC сам по собі не обходить шифрування VPN.

Чим небезпечні витоки WebRTC

Розкритий публічний IP може видати вашого мережевого провайдера та приблизне місцезнаходження, але не ім'я й не точну адресу. Крім того, він може призвести до такого:

• Зіставлення різних браузерних сесій між собою.

• Обмеження за місцезнаходженням.

• Додаткова верифікація або перевірка акаунта.

Це можливі наслідки, а не гарантовані. Проте краще дотримуватися обережності й регулярно проводити тести на витік WebRTC.

Чим відрізняються витоки DNS і WebRTC

Витоки DNS пов'язані з тим, куди йдуть запити на розв'язання доменних імен; витоки WebRTC — з тим, які адреси розкриваються під час визначення параметрів підключення. Один тест не замінює інший.

DNS-тест зазвичай виявляє рекурсивні резолвери, а не публічний IP вашого пристрою. Несподіваний резолвер варто перевірити, але лише його країна не доводить витоку.

Як перевірити витоки WebRTC

По суті, тест на витік WebRTC перевіряє, чи з'являється ваш справжній IP серед ICE-кандидатів, видимих у браузері. Для цього підійдуть спеціальні сервіси: BrowserLeaks, IPLeak або офіційний інструмент WebRTC — Trickle ICE на GitHub.

1. Дізнайтеся свої IPv4 та IPv6 без проксі/VPN

• Закрийте робочі сесії з важливими даними, перш ніж вимикати захист.

• Відкрийте IPLeak.

• Запишіть свій прямий публічний IPv4 та IPv6, якщо він є.

• Не показуйте ці вихідні адреси стороннім.

Повідомлення «No IPv6 detected» означає лише те, що тест не встановив IPv6-з'єднання, але не те, що IPv6 не може з'явитися пізніше.

2. Увімкніть проксі/VPN і перевірте IP ще раз

Підключіть VPN або налаштуйте проксі CyberYozh App у потрібному профілі браузера чи клієнті.

• Відкрийте нову вкладку для тесту.

• Переконайтеся, що публічний IP змінився на очікувану вихідну адресу.

• Перевірте IPv4 та IPv6 окремо.

Зміна IP під час перегляду сайтів підтверджує, що маршрут з'єднання змінився, але витоки WebRTC все одно можуть залишитися.

3. Відкрийте BrowserLeaks, IPLeak або Trickle ICE від WebRTC

Виберіть онлайн-тест на витік WebRTC:

• BrowserLeaks: вивчіть поле «Your WebRTC IP» і журнал SDP.

• IPLeak: скористайтеся його комбінованим тестом на витоки DNS і WebRTC.

• Trickle ICE: приклад із проєкту WebRTC; натисніть «Gather candidates» і вивчіть стовпці з адресами та типами. Це діагностичний приклад, а не повноцінна перевірка приватності.

4. Перевірте, чи немає в результатах вашого фізичного IP

Порівняйте результати тесту на витік WebRTC з вихідними адресами:

• Видно прямий публічний IP провайдера: отже, є витік IP, і причину потрібно знайти.

• Видно очікувану вихідну адресу проксі/VPN: маршрутизація захищена.

• 192.168.x.x або 10.x.x.x: дані приватної мережі, а не ваша публічна адреса.

• Ім'я хоста .local: маскування локальної адреси, але не доказ захисту публічного IP.

Якщо кандидатів немає або з'явилася помилка, результат непереконливий. Перепідключіться й повторіть перевірку в іншому інструменті. Якщо жоден із них не показує витоків, усе гаразд. Про те, як запобігти витокам, читайте далі.

Як запобігти витокам WebRTC

Вимикайте WebRTC, якщо він не потрібен, а якщо дзвінки та застосунки реального часу мають працювати, налаштуйте примусову захищену маршрутизацію. Блокування UDP в обхід проксі допомагає, але не замінює тест на витік WebRTC, який показує реальну картину.

У звичайних браузерах

Скористайтеся відповідним гайдом із налаштування браузера, а потім застосуйте потрібне налаштування:

• Firefox для ПК: about:config → media.peerconnection.enabled → false. Це вимикає WebRTC.

• Chrome: використовуйте підтримуване розширення для приватності з опцією disable_non_proxied_udp.

• Brave: знайдіть у налаштуваннях пункт «WebRTC IP Handling Policy» і виберіть «Disable Non-Proxied UDP».

• Microsoft Edge: використовуйте сумісне розширення для захисту WebRTC або керовану політику; потім повторіть тест.

• Safari: використовуйте примусову маршрутизацію через VPN на рівні пристрою; не покладайтеся на застарілі інструкції з експериментальним меню.

• Opera: увімкніть блокування UDP в обхід проксі, якщо воно доступне, або використовуйте підтримуване сумісне розширення.

В антидетект-браузерах

Дотримуйтеся інструкцій для антидетект-браузерів.

Призначте проксі профілю, а потім перевірте його налаштування WebRTC. Якщо WebRTC не потрібен, виберіть режим «вимкнено»; в інших випадках використовуйте опцію захищеної маршрутизації від розробника браузера. 

Режими на кшталт «Altered» у різних продуктах працюють по-різному: підміна кандидатів, що відображаються, сама по собі не гарантує, що мережевий трафік захищений. 

Після налаштування протестуйте кожен профіль.

У проксі-клієнтах

Дотримуйтеся інструкцій для проксі-клієнтів. Потім:

1. Імпортуйте облікові дані CyberYozh. 

2. Увімкніть режим TUN/повної маршрутизації, якщо він підтримується.

3. Переконайтеся, що вищестоящий проксі підтримує UDP.

4. Спрямуйте DNS потрібним маршрутом

5. Вимкніть небажаний прямий доступ у разі збою. 

Режим системного проксі сам по собі не дорівнює тунелю для всього пристрою. Після налаштування ще раз перевірте реальну конфігурацію браузера на витоки WebRTC.

Налаштування системного файрвола

Зверніться до відповідного гайда з налаштувань ОС.

Увімкніть kill switch для VPN у налаштуваннях Wi-Fi або додайте правила для вихідного трафіку, які дозволяють захищеним застосункам виходити в мережу лише через тунель або проксі-клієнт. Охопіть і IPv4, і IPv6. Так увесь прямий трафік в обхід проксі буде заблоковано, а ризик витоку WebRTC зменшиться. 

Рекомендації щодо роботи з урахуванням витоків WebRTC

• Тестуйте саме той робочий профіль, яким користуєтеся, а не лише браузер за замовчуванням: дозволи, розширення, призначені проксі та правила маршрутизації в різних середовищах можуть відрізнятися.

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

• Перевіряйте DNS та IPv6 окремо: вимкнення WebRTC не виправить маршрутизацію резолвера й не завадить звичайним з'єднанням іти в обхід захищеного мережевого маршруту.

• Перевірте поведінку у разі збою до початку робочої експлуатації: вимкніть тунель і переконайтеся, що захищені застосунки перестають підключатися, а не перемикаються мовчки на прямий доступ.

• Збережіть потрібну функціональність: після запровадження обмежень протестуйте дзвінки та демонстрацію екрана, а потім задокументуйте робочу конфігурацію, не зберігаючи паролі від проксі та не публікуючи вихідні адреси.