Що робити, якщо антидетект браузер показує витік WebRTC? Посібник з діагностики та виправлення MostLogin

Огляд змісту: коли під час перевірки бізнесу WebRTC показує витік, слід негайно припинити вхід або операції з важливими обліковими записами, закрити поточне середовище, а потім перевірити підключення проксі, режим WebRTC, IPv6 та правила обходу проксі. Для користувачів MostLogin типовий порядок дій: підтвердити успішне виявлення проксі, встановити WebRTC середовища у значення Private (Приватний); якщо бізнесу зовсім не потрібні аудіо/відео або peer-to-peer зв'язок, можна обрати Disabled (Вимкнено); одночасно увімкнути правило захисту, що забороняє відкриття середовища при збої проксі.

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

Що таке WebRTC? Чому він може обходити звичайні налаштування проксі?

WebRTC — це абревіатура від Web Real-Time Communication, тобто «веб-комунікація в реальному часі». Він дозволяє браузерам безпосередньо здійснювати голосові дзвінки, відеоконференції, спільний доступ до екрана та передачу даних peer-to-peer. Багато інструментів для онлайн-нарад, клієнтської підтримки та співпраці використовують його.

Щоб знайти доступний шлях з'єднання між двома пристроями, WebRTC збирає кілька «кандидатських адрес» через ICE. Ці кандидати можуть включати адреси мережевих інтерфейсів пристрою, публічні адреси, відображені, виявлені через STUN-сервери, та адреси, ретрансльовані через TURN-сервери. Документація MDN про типи кандидатів ICE показує, що кандидати host представляють прямі адреси пристрою, кандидати srflx генеруються взаємодією STUN/TURN, а кандидати relay проходять через ретрансляцію TURN. MDN: опис з'єднання WebRTC

Це також є першопричиною витоків WebRTC: веб-сторінка створює з'єднання WebRTC через JavaScript і зчитує кандидати ICE. Якщо браузер правильно не обмежує ці адреси, мережева інформація, яку бачить сторінка, може не відповідати виходу проксі. MDN також чітко зазначає, що адреси кандидатів ICE можуть розкривати інформацію про розташування пристрою та топологію мережі, що виходить за межі очікувань користувача, і може використовуватися для ідентифікації відбитка браузера. MDN: примітки щодо безпеки RTCIceCandidate

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

Що саме вважається витоком WebRTC?

Для визначення витоку недостатньо просто перевірити, чи з'явилася IP-адреса на тестовій сторінці. Потрібно порівняти «що показує сторінка» з «що повинно бути видно в цьому середовищі».

Сучасні браузери можуть використовувати mDNS-імена замість IP-адрес локальної мережі, тому поява на тестовій сторінці результату у вигляді випадкового рядка з .local не означає розкриття реальної публічної IP. Дійсно варто звернути увагу на те, чи з'явилися реальні публічні адреси ISP, які ви виявили поза браузерним середовищем.

Які наслідки витоку WebRTC?

1. Конфлікт між ідентичністю проксі та реальною мережевою ідентичністю

Припустимо, середовище MostLogin налаштоване на проксі Нью-Йорка (США), запити веб-сторінок також показують IP Нью-Йорка, але WebRTC розкриває публічну IP локальної мережі користувача. Платформа бачить не природне, стабільне середовище перегляду, а два конфліктуючі сигнали з'єднання з різними географічними розташуваннями або мережевими операторами.

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

2. Різні середовища браузера можуть бути пов'язані через одну реальну IP

Команда створює кілька незалежних середовищ для різних тестових проектів, кожне з різним проксі. Якщо всі ці середовища розкривають одну й ту ж офісну публічну IP через WebRTC, веб-сайт може отримати повторний сигнал зв'язку між середовищами. Навіть якщо Cookie, Canvas та WebGL ізольовані окремо, повторний реальний мережевий вихід знижує незалежність між середовищами.

3. Розкриття приблизного розташування, мережевого оператора та структури мережі

Публічна IP зазвичай може бути використана для визначення країни, міста та мережевого оператора; адреси локальної мережі, IPv6 або різні мережеві інтерфейси можуть розкрити додаткові характеристики топології мережі. IP зазвичай не може окремо визначити точну адресу або реальне ім'я, але може бути використаний разом з обліковими записами, Cookie, відбитками пристрою та поведінковими даними.

4. Відеоконференції та веб-дзвінки можуть мати компроміс між «приватністю та зручністю»

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

Антидетект браузер показує витік WebRTC — виконайте ці 6 кроків

Крок 1: Призупиніть конфіденційні операції в поточному середовищі

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

• Адресу, показану звичайною IP-перевіркою;
• IPv4 та IPv6, виявлені перевіркою WebRTC;
• Адресу проксі та країну/регіон, налаштовані в MostLogin;
• Час тесту, назву середовища та чи використовується VPN.

Запис інформації потрібен для визначення проблеми. Не рекомендується зберігати паролі проксі, Cookie облікових записів або інші облікові дані на знімках екрана.

Крок 2: Встановіть відповідність «Реальна IP — IP проксі — IP WebRTC»

Виконайте три групи перевірок без відкриття облікових записів бізнесу:

1. У звичайному браузері без проксі перевірте поточну публічну IPv4 та IPv6 як реальну мережеву базову лінію.
2. У вкладці Proxy MostLogin натисніть перевірку IP проксі та запишіть очікуваний вихід.
3. Відкрийте відповідне середовище та прочитайте кандидатські адреси на тестовій сторінці WebRTC.

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

Крок 3: Спочатку виправте проксі, потім налаштуйте WebRTC

Налаштування WebRTC не можуть виправити вже відключений, автентифіковано невдалий або неправильно налаштований проксі. Перейдіть на сторінку редагування цільового середовища, відкрийте вкладку Proxy, перевірте протокол, хост, порт, обліковий запис і пароль, потім виконайте перевірку IP проксі. Офіційний посібник MostLogin зі створення середовищ зазначає, що зараз можна налаштувати direct, http, https та socks5, а результат з'єднання можна перевірити через «Check proxy IP». MostLogin: Створення нового середовища

Продовжуйте до наступного кроку лише після успішної перевірки проксі та підтвердження очікуваної країни та міста.

Крок 4: Оберіть відповідний режим WebRTC у MostLogin

Шлях зазвичай:

Profiles (Список середовищ) → Оберіть цільове середовище → Edit (Редагувати) → Fingerprint (Відбиток) → WebRTC

Офіційна документація MostLogin показує випадаючі налаштування WebRTC, де Private використовується для приховування реальної IP при збереженні функціональності WebRTC, а також можуть бути доступні Public та Disabled. MostLogin: Опис налаштувань відбитка WebRTC

Для звичайного середовища проксі рекомендується спочатку використовувати Private. Тільки якщо бізнес не залежить від WebRTC або режим Private все ще не задовольняє вимоги ізоляції, тестуйте Disabled. Не робіть висновок про витік лише тому, що тестова сторінка показує «WebRTC enabled»; ключове питання — яку адресу він повернув.

Крок 5: Увімкніть захист від збоїв проксі та перевірте список обходу проксі

Перейдіть до глобальних налаштувань або налаштувань вподобань середовища MostLogin та увімкніть наступний захист:

• Не відкривати середовище при мережевій помилці проксі;
• Не відкривати середовище при зміні IP проксі;
• Не відкривати середовище при зміні країни або регіону проксі;
• Не відкривати середовище при невдалій синхронізації.

MostLogin описує ці налаштування як захисні заходи перед запуском, де захист від мережевих помилок проксі запобігає випадковому розкриттю реальної IP ISP при збої проксі. MostLogin: Profile preferences

Також перевірте Settings → Proxy bypass. Домени, додані до списку обходу, використовуватимуть локальну мережу замість проксі поточного середовища. Офіційна документація MostLogin також чітко зазначає, що обійдені домени доступатимуться через реальне локальне з'єднання. MostLogin: Proxy bypass Якщо тестові сайти, домени автентифікації або їх API/CDN домени знаходяться тут, видаліть непотрібні винятки та збережіть.

Крок 6: Повністю закрийте та перезапустіть середовище, проведіть перехресну перевірку

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

• Звичайна публічна IP, яку показує браузер;
• IPv4 серед кандидатів WebRTC;
• IPv6 серед кандидатів WebRTC;
• DNS, часовий пояс, мова та географічне розташування відповідають регіону проксі.

Критерії успішної повторної перевірки: сторінка перевірки більше не показує реальну публічну IPv4/IPv6 ISP; публічні адреси WebRTC відповідають проксі, ретрансляційному виходу або очікуваній поведінці продукту; результати залишаються стабільними після перезавантаження середовища.

Приклад використання MostLogin: Середовище з проксі Нью-Йорка виявило реальну IPv6

Сценарій

Команда QA веб-сайту, що працює в різних регіонах, створила середовище MostLogin з назвою US-NewYork-QA-01, перевірка HTTP-проксі показує IPv4 Нью-Йорка (США). Після відкриття тестової сторінки звичайна IP все ще Нью-Йорк, але область WebRTC показує публічну IPv6 від місцевого оператора.

Діагностика

Це реальний витік, а не звичайна ситуація з «кількома IP-адресами». Причина в тому, що HTTP-проксі покриває IPv4 запити веб-сторінок, але IPv6 мережевий шлях хоста не обробляється однаково, і кандидати WebRTC все ще можуть розкрити цю адресу.

Обробка

1. Закрийте середовище, щоб припинити подальші спроби входу.
2. Перевірте, чи проксі-сервіс явно підтримує IPv6; якщо ні, використовуйте проксі-рішення з повним покриттям IPv4/IPv6 або вимкніть незахищені IPv6 шляхи на рівні системи.
3. Відредагуйте середовище, у Fingerprint → WebRTC оберіть Private.
4. Увімкніть «Не відкривати середовище при мережевій помилці проксі».
5. Перевірте список обходу проксі, видаліть виняткові домени, пов'язані з тестовим сайтом.
6. Перезапустіть середовище для повторної перевірки, підтвердьте, що реальна IPv6 більше не з'являється.

У цьому сценарії лише зміна режиму WebRTC може тимчасово усунути виявлення, але покриття IPv6 проксі залишається основною проблемою, тому потрібно перевірити обидва аспекти.

Приклад використання MostLogin: Тестова сторінка показує .local, але публічна IP збігається з проксі

Сценарій

Користувач використовує британський проксі, звичайна IP та публічна адреса WebRTC обидві показують Велику Британію; тестова сторінка додатково показує випадковий рядок, що закінчується на .local, і користувач помилково вважає, що стався витік.

Визначення

.local зазвичай є ознакою того, що браузер приховує адреси локальної мережі за допомогою імен mDNS. Поки не з'являється реальна публічна IPv4/IPv6 ISP і публічні кандидати збігаються з британським проксі, не можна визначити витік реальної IP лише на основі .local.

Обробка

Залиште поточні налаштування Private, запишіть результат і перехресно перевірте на іншій тестовій сторінці. На цьому етапі часта зміна проксі, рандомізація відбитків або перебудова середовища можуть, навпаки, створити більше змін у середовищі, яке повинно бути стабільним.

Приклад використання MostLogin: Після вимкнення WebRTC відеоконференція не підключається

Сценарій

Команда віддаленої підтримки встановила WebRTC у значення Disabled, після чого веб-дзвінки підтримки та спільний доступ до екрана не можуть встановити з'єднання.

Обробка

Змініть середовище на Private, збережіть нормальне підключення проксі, потім повторно перевірте адреси WebRTC. Якщо реальна IP більше не з'являється і аудіо/відео відновлюється, можна поєднати функціональність з ізоляцією мережі. Якщо витік продовжується в режимі Private, слід перевірити протокол проксі, IPv6, маршрутизацію VPN та домени обходу, а не обирати Public просто для відновлення дзвінків.

Якщо витік продовжується після виправлення, де може бути проблема?

Якщо MostLogin вже налаштований на Private, але тест все ще показує реальну публічну IP, продовжте перевірку в такому порядку:

1. Проксі фактично не підключений. При помилкових облікових даних, застарілому вузлі або офлайн проксі-сервері браузер може не отримати очікуваний вихід.
2. IPv6 не охоплена. Проксі обробляє лише IPv4, хост все ще може отримати доступ до мережі через реальну IPv6.
3. Правила обходу проксі. Тестовий сайт або пов'язані піддомени налаштовані на пряме підключення.
4. Розділення VPN або конфлікт системної маршрутизації. Одночасне використання VPN, системного проксі та проксі середовища може створити різні мережеві шляхи.
5. Старий процес середовища все ще працює. Після збереження налаштувань середовище не було повністю закрито, старий процес все ще використовує початкову конфігурацію.
6. Розширення браузера змінює мережеву поведінку. Розширення VPN, проксі, приватності або WebRTC можуть конфліктувати з налаштуваннями середовища.
7. Хибне спрацювання або кеш сторінки перевірки. Використовуйте другу тестову сторінку та перезапустіть середовище для перевірки, не робіть висновків на основі єдиного результату.

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

Контрольний список перевірки захисту від витоку WebRTC

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

•  Перевірка IP проксі MostLogin успішна;
•  WebRTC встановлено на Private або Disabled, якщо реальна комунікація не потрібна;
•  Звичайна публічна IP збігається з очікуваним виходом проксі;
•  WebRTC не показує реальну публічну IPv4 ISP;
•  WebRTC не показує реальну публічну IPv6 ISP;
•  DNS, часовий пояс та мова не мають явних конфліктів з розташуванням проксі;
•  Захист від помилок проксі та змін IP увімкнено;
•  У Proxy bypass немає непотрібних доменів прямого підключення;
•  Після перезапуску середовища результати перевірки залишаються незмінними.

Поширені запитання

Чи означає обов'язково витік, якщо тест WebRTC показує кілька IP?

Не обов'язково. Кілька результатів можуть походити від IPv4, IPv6, інтерфейсів локальної мережі, відображень STUN, ретрансляції TURN або mDNS. Тільки поява реальної публічної IP ISP, непов'язаних мережевих виходів або публічних адрес, що явно конфліктують з розташуванням проксі, повинна розглядатися як високоризиковий витік.

Яку IP повинен показувати WebRTC після використання проксі?

В ідеалі веб-сторінка не повинна бачити вашу реальну публічну IP ISP. Залежно від браузера та політики продукту, тестова сторінка може показати адресу проксі, ретрансляційну адресу, приховані локальні кандидати або не показувати доступні адреси. Критерій не «повинна бути лише одна IP», а «не повинно бути реальних публічних виходів, які потрібно ізолювати».

Який режим обрати в MostLogin — Private чи Disabled?

Якщо потрібні аудіо/відео, клієнтські дзвінки або спільний доступ до екрана, оберіть Private та повторно протестуйте; якщо функції WebRTC зовсім не використовуються, можна обрати Disabled. Disabled може вплинути на функціональність веб-сайту, тому це не оптимальне рішення для всіх середовищ.

Чи може витік WebRTC розкрити реальне ім'я та точну адресу?

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

Після одноразового витоку достатньо лише виправити налаштування?

Виправлення може лише запобігти подальшому розкриттю, але не може відкликати дані, які вже отримав веб-сайт. Для важливого бізнесу слід перевірити часовий діапазон витоку, постраждалі середовища та записи входу; за необхідності завершити старі сесії, оновити облікові дані та спостерігати за появою незвичайних перевірок на платформі.

Висновок

Суть витоку WebRTC — не «чи увімкнено WebRTC», а чи розкриває він реальні публічні адреси, несумісні з поточним середовищем проксі. Після виявлення аномалії слід призупинити конфіденційні операції, потім виконати порівняння трьох наборів даних: реальна IP, IP проксі та IP WebRTC. Користувачі MostLogin зазвичай можуть вирішити проблему, перевіривши підключення проксі, обравши WebRTC Private, увімкнувши захист від збоїв проксі, очистивши непотрібні правила обходу проксі та перевіривши шляхи IPv6.

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