Проксі може охоплювати HTTP-трафік, тоді як WebRTC обмінюється адресами-кандидатами через STUN/ICE по UDP. У статті пояснюється, коли можуть розкриватися локальні й приватні адреси та як узгодити мережевий вихід із середовищем браузера.
Проксі вже налаштовано, а сторінка перевірки IP показує очікуваний регіон і провайдера. Мережева ідентичність виглядає коректно. Але варто відкрити тест на витоки, як секція WebRTC стає червоною й показує адресу вашого реального інтернет-з’єднання.
Не поспішайте одразу міняти проксі. У більшості випадків проблема не в його якості, а в трафіку, який він не контролює.
Проксі обробляє HTTP, а WebRTC використовує інший шлях
Проксі працює на мережевому рівні. Незалежно від того, чи реалізований він як розширення браузера, чи як системний тунель, він обробляє HTTP/HTTPS-запити й спрямовує цей трафік через вихід проксі.
WebRTC працює інакше. Це вбудована в браузер можливість зв’язку в реальному часі. Щоб аудіо-/відеодзвінки та P2P-передавання знайшли придатний маршрут, браузер може активно надсилати STUN-запити зовнішнім серверам — по суті запитуючи: «Яку адресу ви бачите для мене?» — а потім оформлювати відповіді як ICE-кандидати та передавати їх вебсторінці. Ці запити використовують UDP, тобто канал, незалежний від HTTP-тунелю.
У результаті виникає розбіжність: запити вебсторінки виходять через проксі, а браузер водночас може повідомити локальну адресу. Припущення, що налаштований проксі автоматично означає повністю “чисту” мережеву ідентичність, є найпоширенішою відправною точкою цієї проблеми.
Розкриватися може не лише публічна IP-адреса
ICE-кандидати зазвичай містять два типи адрес. Перший — публічна адреса, тобто вихід вашого реального інтернет-провайдера. Другий — локальна адреса, наприклад приватна адреса, що починається з 192.168; іноді також може з’являтися адреса віртуального мережевого адаптера.
Сама по собі адреса приватної мережі мало що доводить, адже вона є майже в кожного комп’ютера. Однак вона може бути достатньо стабільною, щоб повторювані збіги адрес-кандидатів у кількох облікових записах стали для платформи додатковим сигналом для прив’язки їх до одного пристрою. Публічна адреса пряміша: вона вказує на реального провайдера й приблизний географічний регіон. Точність залежить від платформи, але принцип зрозумілий: що реальніша адреса, то простіше виконати прив’язку.
Коли сайт справді може прочитати адресу?
Не кожен сайт намагається це робити. Для обміну адресами сторінка має активно створити об’єкт RTCPeerConnection, чого звичайні контентні сторінки зазвичай не потребують.
Найчастіше це трапляється на сайтах, яким потрібен зв’язок у реальному часі, наприклад у сервісах відеоконференцій, онлайн-підтримки та на деяких сторінках прямих трансляцій; на сайтах, що значною мірою залежать від реклами або протидії шахрайству; а також на платформах із розвиненими системами контролю ризиків. Зчитування відбувається поза видимою частиною інтерфейсу, а після збору даних ви зазвичай не отримуєте повідомлення про те, як їх використають далі.
Є й ситуація, не пов’язана із самим сайтом. У короткий проміжок, коли проксі перепідключається або перемикається на інший вузол, STUN-запит браузера може піти через локальну мережу. Вікно дуже коротке, але його достатньо, щоб зафіксувати одну подію.
Три поширені сценарії збою
Проксі у вигляді розширень браузера зазвичай перехоплюють лише HTTP/HTTPS-запити. UDP залишається поза їхньою зоною дії, і вибір опції «глобально» в інтерфейсі цього не змінює.
Системний глобальний проксі виглядає повнішим, оскільки охоплює трафік усього пристрою. Однак збирання адрес-кандидатів може напряму прив’язуватися до локального мережевого інтерфейсу й обходити системну таблицю маршрутизації, залишаючи прогалину в тунелі на цьому етапі.
Третя проблема не суто технічна, а пов’язана з розвитком систем контролю. Системи ризик-менеджменту дедалі частіше використовують WebRTC-адреси як один із сигналів для пов’язування облікових записів. Дані, які раніше не вимірювали або ігнорували, тепер можуть враховуватися під час оцінки.
Мета — узгоджений мережевий вихід, а не просто вимкнення одного перемикача
Є кілька загальних підходів. Якщо робочому процесу зовсім не потрібен зв’язок у реальному часі, найпростіше вимкнути WebRTC. Ціна цього — недоступність таких функцій, як відеодзвінки та онлайн-підтримка.
Якщо ці функції потрібно зберегти, поширений підхід — зробити адресу, яку повертає рівень WebRTC, узгодженою з виходом проксі. Надійніший варіант — також спрямовувати STUN-запити через проксі-канал, щоб інтерфейс не розкривав локальну адресу. Якщо потрібні P2P або відеодзвінки, через проксі має проходити весь UDP-трафік, а не лише HTTP-рівень.
Поширена помилка — вважати, що одного вимкнення WebRTC достатньо для “чистого” середовища. Насправді важлива взаємна узгодженість мережевого виходу, DNS-резолвінгу, належності IP та ASN, часового поясу й мови, а також характеристик пристрою. Будь-яка невідповідність може залишити аномальний сигнал; WebRTC — лише один із пунктів, які найпростіше не помітити.
Перевірка проста. Проведіть тест після зміни вузла й ще раз перед звичайним використанням середовища: відкрийте тест на витоки та перевірте, чи секція WebRTC показує вихід проксі, локальну адресу або справжню публічну адресу. Звичайна перевірка IP цього не показує.
Ізоляція середовищ на рівні рушія браузера дає змогу задати окрему політику WebRTC-адрес для кожного середовища й поєднати її з відповідним мережевим виходом. PurpleMark надає саме такий тип можливостей. Якщо кілька середовищ використовують один вихід або їхні адресні політики не узгоджені, цінність ізоляції значно зменшується.
Це лише технічне пояснення. Використовуйте відповідні інструменти з дотриманням правил платформ і місцевого законодавства.
