UKВитік WebRTC відбувається, коли веб-переглядач розкриває інформацію про мережеву адресу, яку, як ви очікували, VPN, проксі-сервер або налаштування конфіденційності приховають. Найяскравішим прикладом є загальнодоступна IP-адреса вашого провайдера, яка відображається замість IP-адреси VPN або проксі-сервера, яку ви планували використовувати.
Сама по собі WebRTC не є шкідливою функцією. Він підтримує відеодзвінки, голосовий чат, спільний доступ до екрана та дані в реальному часі в браузері. Проблема конфіденційності виникає через те, як він шукає робочий мережевий шлях.
Простіше кажучи, Витік WebRTC означає, що браузер відкриває неочікувану адресу під час підготовки з’єднання в реальному часі.
Що таке Витік WebRTC?
Слово витік потребує контексту. Веб-сайт зазвичай бачить загальнодоступну IP-адресу, яка використовується для завантаження сторінки. Тест WebRTC також може показати ту саму адресу. Якщо обидва результати вказують на вибраний вами VPN або проксі, можливо, витоку взагалі немає.
Проблема починається, коли WebRTC виявляє адресу за межами очікуваного маршруту. Ви можете побачити IP-адресу VPN під час звичайної перевірки IP-адреси, а потім знайти IP-адресу домашнього провайдера в результатах WebRTC. Ви також можете виявити відкриту адресу IPv6, яку пропустив перший тест.
Я не розглядаю кожен рядок у засобі перевірки витоків як помилку. Я шукаю адресу, яку поточне налаштування мало приховати.
Коли вплив IP стає витоком
Припустімо, що ваша звичайна адреса провайдера знаходиться в Лондоні. Ви підключаєтеся до проксі-сервера в Нью-Йорку. Стандартний засіб перевірки IP тепер показує проксі-сервер New York. Ця частина працює, як очікувалося.
Потім ви запускаєте тест WebRTC. Якщо він також показує адресу Нью-Йорка, сигнали мережі погоджуються. Якщо також відображається оригінальна адреса лондонського провайдера, браузер відкрив неочікуваний шлях.
Така ж логіка стосується і VPN. Це також стосується IPv6. Захищений маршрут IPv4 не дуже допомагає, якщо окрема адреса IPv6 усе ще вказує на вихідну мережу.
Навіщо WebRTC потрібні мережеві адреси
Для спілкування в реальному часі потрібен шлях між двома кінцевими точками. Цей шлях може бути прямим. Він може проходити через пристрій NAT. Може знадобитися реле, якщо не вдається встановити пряме з’єднання.
WebRTC збирає можливі маршрути, щоб вибрати той, який працює. Це допомагає дзвінкам починатися швидше та зменшує затримку. Це також означає, що веб-додаток може дізнатися більше про мережу, ніж із звичайного запиту сторінки.
Цей процес окремий від доступу до камери та мікрофона. Сторінка може створити однорангове з’єднання або канал даних і почати збирати кандидатів на з’єднання. Для доступу до мультимедійних пристроїв все ще потрібен відповідний дозвіл браузера.
Як відбувається Витік WebRTC?
Процес починається з RTCPeerConnection. Веб-програма створює цей об’єкт, коли їй потрібне з’єднання в реальному часі. Потім браузер використовує Interactive Connectivity Establishment, який зазвичай називається ICE, щоб зібрати можливі кандидати на з’єднання.
Ці кандидати описують способи роботи зв’язку. Веб-додаток може зчитувати інформацію про кандидата та ділитися нею з віддаленою стороною через свою сигнальну систему.
Якщо браузер містить адресу постачальника послуг Інтернету, яка мала бути за VPN або проксі, програма може її побачити. Це може статися через розділене тунелювання, додатковий мережевий інтерфейс, незахищений маршрут IPv6 або проксі-сервер браузера, який все ще дозволяє WebRTC підключатися поза очікуваним шляхом.
Збір кандидатів ICE
Потік має п'ять кроків:
- Сторінка створює
RTCPeerConnection. - Агент ICE перевіряє доступні шляхи підключення.
- Браузер збирає кандидатів на хост, STUN або ретранслятор TURN.
- Додаток отримує кандидатів, яких йому дозволено бачити.
- ICE перевіряє пари кандидатів і вибирає робочий шлях.
ICE не є сервером. Це процес, який використовується для пошуку та тестування варіантів підключення. STUN і TURN підтримують цей процес різними способами.
Кандидати в хост, STUN і TURN
Кожен тип кандидата розкриває іншу частину зв’язку.
| Тип кандидата | Звідки походить | Що це може виявити |
|---|---|---|
| Хост | Інтерфейс локальної мережі | Локальний IP або ім’я mDNS |
| Серверно-рефлексивний | Загальнодоступна адреса, отримана через STUN | Публічна IP-адреса, яка використовується для доступу до сервера STUN |
| естафета | Адреса, надана сервером TURN | Адреса сервера ретрансляції, а не пряма адреса кінцевої точки |
Ретранслятор TURN може зберігати прямі адреси кінцевих точок подалі від віддаленого вузла. Він також додає інший сервер до шляху. Це може збільшити затримку, вартість смуги пропускання та робочу залежність від реле.
Коли VPN або проксі відкриває неочікуваний шлях
VPN і проксі не слід розглядати як один і той самий інструмент. VPN з повним тунелем може направляти широкий трафік пристрою та використовувати правила брандмауера, щоб зупинити трафік за межами тунелю. VPN із розділеним тунелем дозволяє вибраному трафіку використовувати інший маршрут.
Проксі-сервер браузера часто обробляє веб-запити для одного браузера або профілю. Він може не контролювати кожен шлях WebRTC. SOCKS5 може підтримувати UDP, але фактична маршрутизація WebRTC усе ще залежить від браузера та його конфігурації.
Проксі-сервери, VPN та браузери антивиявлення керують різними рівнями. Проксі-сервер направляє вибраний трафік. VPN може керувати ширшим зашифрованим тунелем. Антидетект-браузер керує профілями веб-переглядача та сигналами на стороні веб-переглядача. Одне не замінює автоматично інші.
Яку інформацію може відкрити WebRTC?
Більшість тестових сторінок показують більше одного поля. Мітки можуть виглядати тривожно, особливо коли місцеві та публічні адреси з’являються разом. Це допомагає оцінити кожен тип окремо.
Публічні IP-адреси
Загальнодоступна IP-адреса відображається в Інтернеті. Він може вказувати провайдера, ASN, широке розташування та тип мережі, що використовується.
Коли VPN або проксі активні, найважливішим попередженням є поява загальнодоступної IP-адреси базового провайдера. Це може бути адреса IPv4, адреса IPv6 або обидва.
IP-адреса зазвичай сама по собі не розкриває точну домашню адресу. Це все ще корисна мережева інформація. Це також може конфліктувати з розташуванням і провайдером, які показує очікувана IP-адреса виходу.
Локальні IP-адреси та імена mDNS
Локальні адреси часто починаються з таких діапазонів, як 192.168 або 10. Ці адреси повторно використовуються в багатьох приватних мережах. Одна локальна IP зазвичай менш показова, ніж публічна адреса провайдера.
Це не втрачає сенсу місцеву інформацію. Це може виявити частину макета мережі. Стабільна комбінація локальних інтерфейсів також може додати інший сигнал під час порівняння сеансів.
Сучасні веб-переглядачі часто приховують адресу локального хосту за випадковим іменем mDNS .local. Якщо побачити це ім’я, це не означає, що загальнодоступна IP-адреса вашого провайдера злилася. Це означає, що браузер уникає прямого доступу до локальної адреси. Він також не видаляє всі можливі сигнали WebRTC.
IPv6 і кілька мережевих інтерфейсів
Багато людей перевіряють IPv4 і зупиняються на досягнутому. Це легко зрозуміти. IPv4 все ще є адресою, яку впізнає більшість користувачів.
IPv6 потребує власної перевірки. VPN може правильно обробляти IPv4, тоді як інша конфігурація залишає IPv6 видимим. Wi-Fi, Ethernet, віртуальні адаптери та інтерфейси VPN також можуть створити кілька кандидатів.
Результати залежать від браузера, операційної системи, мережі та політики конфіденційності. Тест налаштувань, які ви використовуєте, скаже вам більше, ніж загальний список браузера.
Як перевірити наявність Витік WebRTC
Чистий тест починається з базової лінії. Без нього ви можете бачити кілька адрес і не матимете надійного способу дізнатися, яка з них належить до вихідного з’єднання.
Покрокова перевірка Витік WebRTC
- Відключіть VPN або проксі.
- Запишіть поточні публічні адреси IPv4 та IPv6.
- Закрийте тестову сторінку.
- Підключіть VPN або проксі або запустіть профіль браузера, який потрібно перевірити.
- Використовуйте звичайний засіб перевірки IP-адреси, щоб підтвердити очікувану IP-адресу виходу.
- Відкрийте засіб перевірки WebRTC.
- Порівняйте загальнодоступні, локальні, mDNS, IPv6 і результати ретрансляції з базовим рівнем.
- Змініть відповідне налаштування та знову перевірте, чи з’являється оригінальна адреса провайдера.
Елементи керування браузера змінюються з часом. Ретельний Витік WebRTC має більше значення, ніж старий список нібито безпечних налаштувань.
Як читати результати тесту
| Результат тесту | Загальне тлумачення |
|---|---|
| Публічна IP-адреса WebRTC збігається з IP-адресою VPN або проксі-сервера | Результат зазвичай йде за очікуваним шляхом |
| З’являється загальнодоступна IP-адреса базового провайдера | Є важливий Витік WebRTC |
З’являється випадкова назва .local | Адресу локального хоста приховано через mDNS |
| Відображається лише адреса реле TURN | Для підключення використовується кандидат на ретрансляцію |
| WebRTC недоступний | WebRTC вимкнено або обмежено, тому пов’язані функції можуть не працювати |
Один тест BrowserLeaks від MoreLogin перевірив IP, WebRTC, часовий пояс, мову, Canvas, WebGL і шрифти в тому самому профілі.
Це був один тест на одній конфігурації. Це не слід сприймати як обіцянку для кожної версії браузера, пристрою, проксі-сервера чи профілю.
Чому один зелений результат не є постійною гарантією
Зелений результат заспокоює. Я б все одно не ставився до цього як до сертифіката, термін дії якого ніколи не закінчується.
Перевірте ще раз після будь-яких змін, які можуть вплинути на браузер або мережу:
- Оновлення браузера
- Новий VPN-сервер або проксі
- Зміна розширення
- Нова мережа
- IPv6 увімкнено
- Новий профіль браузера
- Інша політика WebRTC
Тест на витік — це знімок одного браузера, мережі та конфігурації. Цього достатньо, щоб прийняти корисне рішення. Це не є постійною гарантією конфіденційності.
Як запобігти або виправити Витік WebRTC
Немає єдиного виправлення, яке б відповідало кожному браузеру та кожному робочому процесу. Правильний вибір залежить від того, чи потрібно залишати доступними функції WebRTC.
Використовуйте VPN із перевіреним захистом від витоку
VPN на системному рівні може захищати трафік WebRTC за допомогою правил маршрутизації та брандмауера. Перевірте, чи активне розділене тунелювання. Також перевірте IPv6. Потім запустіть тест замість того, щоб довіряти статусу підключення в програмі.
Бренд VPN має менше значення, ніж спостережуваний результат на пристрої та в браузері, які ви фактично використовуєте.
Обмежте трафік без проксі або використовуйте WebRTC лише для ретрансляції
Інший варіант – заборонити WebRTC використовувати шлях за межами проксі. Деякі елементи керування блокують UDP без проксі. Інші форсують трафік через налаштований проксі.
Якщо UDP не може використовувати цей маршрут, WebRTC може повернутися до TCP або TURN. Це також може вийти з ладу. Від виконання залежить результат.
WebRTC лише для ретрансляції використовує кандидати TURN. Він може утримувати прямих кандидатів від віддаленого партнера, зберігаючи зв’язок у реальному часі. Компромісом є більша затримка, більше релейного трафіку та більша залежність від доступності TURN.
Змініть налаштування браузера або скористайтеся розширенням
Firefox пропонує розширені налаштування, які можуть обмежити або вимкнути WebRTC. Браузери на базі Chromium часто покладаються на розширення, політику підприємства або елементи керування мережею на рівні браузера.
Розширення можуть допомогти. Вони також потребують догляду. Застаріле розширення може перестати працювати після оновлення браузера. Він може запитувати широкі дозволи. Він також може по-різному поводитися в різних версіях браузера.
Якщо ви використовуєте його, виберіть підтримуване джерело та перевірте результат ще раз. Піктограма на панелі інструментів не є доказом. Мережевий результат такий.
Використовуйте елементи керування WebRTC для кожного профілю
Глобальні налаштування стають незручними, коли кілька профілів використовують різні проксі-сервери або мережеві розташування. Кожен профіль потребує чіткого призначення проксі-сервера та політики WebRTC, яка відповідає поставленим завданням.
Профіль не готовий лише тому, що його проксі підключається. Коли ви налаштувати проксі в MoreLogin, підтвердьте видиму IP-адресу та запустіть окрему перевірку WebRTC.
У розділі MoreLogin документація API профілю браузера перераховує параметри WebRTC для кожного профілю як конфіденційність, заміну, справжнє, вимкнене та пересилання. Він не повністю пояснює, як кожен режим обробляє кандидати на хост, STUN, TURN, UDP, IPv4 і IPv6.
Тільки мітки режиму недостатньо. Перевірте вибрану поведінку в поточній версії продукту.
Чи варто відключати WebRTC?
Вимкнення WebRTC може закрити цей шлях виявлення адреси. Це також варіант, який, швидше за все, вплине на звичайні функції браузера.
Що заважає вимкненню WebRTC
Коли RTCPeerConnection недоступний, сторінка не може використовувати цей API для збору тих самих кандидатів на підключення. Це може запобігти витоку IP-адрес на основі WebRTC.
Це не зупиняє витоки DNS. Він не приховує відбиток браузера. Він не видаляє файли cookie або дані облікового запису.
Що може перестати працювати
Сайти можуть втратити функції, які залежать від WebRTC, зокрема:
- Відеодзвінки через браузер
- Голосовий чат
- Спільне використання екрана
- Однорангова передача файлів
- Підтримка в реальному часі та віджети для співпраці
Деякі служби можуть пропонувати інший маршрут. Інші можуть вийти з ладу або втратити якість.
Вимкнути, обмежити або переслати
| метод | Функціонал WebRTC | Контроль конфіденційності | Головний компроміс |
|---|---|---|---|
| Вимкнути | Зазвичай недоступний | Сильний проти цього шляху витоку | Найнижча сумісність |
| Обмежити або примусово використовувати проксі | Часто залишається в наявності | Залежить від реалізації | Потребує ретельного налаштування та повторного тестування |
| Тільки реле | Залишається доступним через TURN | Уникає прямих кандидатів | Додає залежність від затримки, вартості та реле |
Вимкніть WebRTC, якщо профіль не потребує зв’язку в реальному часі. Обмежте або передайте його, коли функція повинна залишатися доступною, а мережевий шлях можна перевірити.
Витік WebRTC проти витоку DNS
Витоки WebRTC і DNS легко сплутати, оскільки обидва можуть послабити конфіденційність. Вони розкривають різну інформацію.
| Витік WebRTC | Витік DNS |
|---|---|
| Виявляє неочікувані мережеві адреси через ICE-кандидатів | Надсилає DNS-запити неочікуваному резолверу |
| Перевірено спеціальним тестом WebRTC | Перевірено за допомогою Тест на витік DNS |
| Виправлено за допомогою політики WebRTC, маршрутизації, проксі-сервера, керування UDP або TURN | Виправлено за допомогою налаштувань DNS-маршрутизації, резолвера та VPN |
І те, і інше може статися одночасно. Виправлення одного не означає, що іншого немає.
Витоки WebRTC і ізольовані профілі браузера
Ідентифікація мережі та ідентифікація браузера знаходяться на різних рівнях. Ця відмінність стає важливою, коли профілі повторно використовуються з часом.
Проксі або VPN контролює мережевий маршрут. Політика WebRTC контролює, як кандидати на з’єднання відображаються чи ретранслюються. Профіль браузера містить файли cookie, локальне сховище, налаштування браузера та інші сигнали.
Інформація WebRTC може стати частиною ширшого відбитка браузера разом із версією веб-переглядача, часовим поясом, шрифтами, виведенням Canvas і поведінкою WebGL.
Підтримуйте узгодженість мережевих сигналів кожного профілю
Перед використанням профілю перевірте частини, які повинні узгоджуватися:
- Очікуваний загальнодоступний IP проксі або VPN
- Публічна IP-адреса WebRTC
- Вплив IPv6
- Поведінка локального IP або mDNS
- Часовий пояс і геолокація
- Мова браузера
Послідовність не робить профіль невидимим. Це зменшує невідповідності, яких можна уникнути, і полегшує діагностику проблем.
Підтвердьте профіль перед важливою роботою
Спокусливо зупинитися, коли звичайна перевірка IP виглядає правильно. Виявлення витоку через кілька днів викликає розчарування, і його важче розплутати.
У MoreLogin профіль браузера з кількома обліковими записами зберігає налаштування проксі-сервера, конфігурацію WebRTC, файли cookie, пам’ять та інші сигнали веб-переглядача в одному багаторазовому середовищі. Це полегшує перегляд налаштувань. Результат залежить від вибраних налаштувань, мережі та проксі.
Протестуйте новий профіль перед його використанням. Перевірте ще раз, коли зміниться проксі-сервер, версія браузера або політика WebRTC.
Ключові висновки
- Витік WebRTC — це несподіване відкриття мережевої адреси, а не поява будь-якої IP-адреси під час тесту.
- ICE може збирати адреси-кандидати типу host, адреси, отримані через STUN, і релейні адреси TURN.
- Корисний тест порівнює базову IP-адресу провайдера з результатом VPN, проксі або профілю.
- Вимкнення, обмеження, проксі-сервер і WebRTC лише з ретрансляцією мають різні компроміси конфіденційності та сумісності.
Поширені запитання щодо Витік WebRTC
Чи завжди через WebRTC витікає ваша справжня IP-адреса?
Ні. Результат залежить від браузера, мережі, маршруту VPN або проксі, конфігурації IPv6 і політики WebRTC. При правильному налаштуванні маршрутизації може відображатися лише IP-адреса VPN або проксі. У налаштуваннях лише реле може відображатися адреса TURN.
Чи може WebRTC обійти VPN або проксі?
Він може надати додаткову адресу, коли браузеру дозволено використовувати інший мережевий шлях. Розділене тунелювання, незахищений маршрут IPv6 або проксі-сервер браузера, який не контролює трафік WebRTC, можуть сприяти цьому результату.
Чи локальна IP-адреса є Витік WebRTC?
Це викриття інформації локальної мережі. Зазвичай це менш прямо, ніж розкриття публічної IP-адреси провайдера. Його значення залежить від адреси, її стабільності, інших наявних інтерфейсів і способу поєднання інформації.
Що означає адреса .local у тесті WebRTC?
Випадкова адреса .local зазвичай є іменем хосту mDNS. Сучасні браузери використовують його, щоб уникнути прямого показу IP локального хоста. Це не означає, що стався витік загальнодоступної IP-адреси провайдера.
Чи може веб-сайт перевіряти WebRTC без дозволу камери?
Сторінка може створити однорангове з’єднання або канал даних і ініціювати збір кандидатів ICE. Для доступу до камери та мікрофона все ще потрібен відповідний дозвіл медіа.
Чи вимкнення WebRTC зламатиме веб-сайти?
Це може вплинути на відеодзвінки, голосовий чат, показ екрана, передачу файлів та інші функції в реальному часі. Деякі сайти можуть надати резервний варіант. Інші можуть втратити функцію або працювати зі зниженою якістю.
Як часто слід перевіряти наявність витоків WebRTC?
Тестуйте після зміни браузера, VPN, проксі-сервера, розширення, мережі, налаштувань IPv6, профілю браузера або політики WebRTC. Швидкий повторний тест може виявити маршрут, який змінився без очевидного попередження.
Упорядковуйте налаштування WebRTC і проксі
Захист WebRTC працює найкраще, якщо він розглядається як частина всього налаштування профілю. Проксі-сервер, видима IP-адреса, маршрут IPv6, часовий пояс, мова та політика WebRTC повинні мати сенс разом.
Спробуйте MoreLogin безкоштовно, щоб створити багаторазові профілі веб-переглядача, окремо налаштувати параметри мережі та браузера та перевірити кожне середовище перед використанням.
