Витоки IP трапляються не лише через WebRTC. DNS, часовий пояс і мова, IPv6 та сторонні скрипти також можуть розкрити реальний мережевий вихід. Тут показано, як перевірити кожен канал і чому узгодженість виходу та середовища надійніша.
IP-адреса — це унікальний ідентифікатор пристрою в мережі, який дає змогу пристроям розпізнавати один одного та обмінюватися даними. Саме через унікальність, якщо стороння особа отримає цю адресу, вона може пов'язати вас із вашою активністю та зробити висновки про звички перегляду, приблизне місцезнаходження й використовуваного мережевого провайдера. Витік не обов'язково означає, що пристрій зламано: це означає, що мережевий вихід, який ви хотіли приховати, став видимим через інший канал.
Найвідоміший приклад — WebRTC. Проте в повсякденній роботі проблеми часто створюють тихіші канали: DNS-резолвінг, додаткові сигнали на кшталт часового поясу й мови, IPv6 та сторонні скрипти на сторінках. Для кожного потрібне окреме рішення, але всі ці канали можна виявити системною перевіркою.
Спочатку розберіться із самою адресою
IP-адреса — це числова мітка, призначена підключеному пристрою. Вона виконує дві функції: ідентифікує хост або мережевий інтерфейс та вказує його положення в мережі. Нині використовуються дві версії. IPv4 — це 32-бітне двійкове число в крапково-десятковому записі, наприклад 192.168.1.1. Теоретично доступно близько 4,3 млрд адрес, але на практиці значно менше через нерівномірний розподіл і приватні діапазони. IPv6 використовує 128 біт і шістнадцятковий запис із двокрапками; адресний простір становить приблизно 3,4×10³⁸, чого практично достатньо для унікальної адреси кожному пристрою.
Версія адреси знову стане важливою далі, бо саме вона визначає, чи може трафік обійти запланований маршрут через IPv6.
Чи йде DNS тим самим маршрутом?
DNS перетворює доменні імена на адреси. Поширена помилка — спрямувати трафік через тунель, але залишити DNS-запити на резолвері місцевого інтернет-провайдера. Тоді вихід, який показує сторінка, може виглядати правильним, але DNS-дані все одно видають джерело.
Самоперевірка: відкрийте сторінку тесту витоку DNS і подивіться, яким мережам належать показані резолвери. Якщо це ваш місцевий провайдер або сервіси, що явно не відповідають регіону потрібного виходу, DNS не слідує за тунелем. Також можна кілька разів оновити сторінку з відкритою панеллю «Мережа» в інструментах розробника та пошукати ознаки прямого локального резолвінгу.
Додаткові сигнали: часовий пояс і мова
Цей канал легко пропустити, бо йдеться не про мережеве налаштування, а про саме середовище. Якщо мережевий вихід вказує на одну країну, а часовий пояс системи, мова інтерфейсу браузера та формат дати — на іншу, тривала невідповідність сама стає слабким сигналом. Однієї ознаки може бути замало, але кілька разом уже можуть дати змогу пов'язати середовище.
Самоперевірка: порівняйте місцезнаходження вихідного IP із часовим поясом, мовою, форматом дати та бажаною розкладкою клавіатури пристрою. Під час роботи з кількома регіонами кожне середовище має бути внутрішньо узгодженим набором, а не результатом постійної зміни часового поясу на одному комп'ютері.
IPv6 — один із каналів, які найпростіше не помітити
Витоки через IPv6 можуть бути малопомітними. Якщо тунель або проксі обробляє лише IPv4, пристрій усе одно може виходити напряму через IPv6, і один рядок IPv6 на тестовій сторінці здатен розкрити реальне місцезнаходження. У багатьох системах IPv6 увімкнено за замовчуванням і він має вищий пріоритет, тому трафік природно обирає цей маршрут.
Самоперевірка: дивіться одночасно на секції IPv4 та IPv6. Якщо IPv6 показує адресу вашого місцевого провайдера, а IPv4 — вихід проксі, цей канал відкритий. Потрібно або спрямувати IPv6 через той самий тунель, або вимкнути його в середовищі, де він не потрібен.
Сторонні скрипти та розширення
Код аналітики, рекламні скрипти, віджети підтримки, шрифти та ресурси CDN можуть ініціювати запити поза основним мережевим шляхом сайту. Такі запити не завжди дотримуються заданих правил проксі, а деякі можуть передавати дані, доступні фронтенду. З розширеннями браузера ситуація подібна: що їх більше, то більше компонентів можуть встановлювати з'єднання, особливо якщо походження розширення незрозуміле.
Самоперевірка: відкрийте ту саму сторінку в приватному вікні, спочатку без розширень, потім з увімкненими, і порівняйте результати тесту. У панелі «Мережа» інструментів розробника можна також фільтрувати запити за доменом і шукати прямі локальні з'єднання або сторонні домени, не пов'язані із самою сторінкою.
WebRTC також варто перевіряти окремо
WebRTC створено для аудіо- й відеозв'язку в реальному часі, і воно може збирати відомості про локальну мережу. Якщо обмеження недостатньо суворі, вебсторінка може через нього прочитати локальні або реальні адреси. WebRTC часто вважають синонімом витоку IP, але насправді це лише один із каналів. Тестові сторінки зазвичай показують і зовнішній IP, і IP, розкриті через WebRTC; розбіжність між ними — сигнал для перевірки.
Краще узгодити вихід і середовище, ніж вимикати параметри по одному
Багато описаних каналів можна закрити окремими перемикачами, але така чиста конфігурація крихка. Зміна мережі, оновлення браузера або встановлення нового розширення можуть непомітно повернути налаштування до стандартного значення.
Стабільніший підхід — діяти навпаки: спочатку визначити, користувача з якого регіону має представляти середовище, а потім налаштувати вихід, DNS, часовий пояс, мову, стан IPv6 і параметри відбитка як єдиний узгоджений набір. Сенс тестування не лише в тому, щоб знайти невимкнений параметр, а в тому, щоб перевірити відповідність усіх частин одна одній.
Коли кількість акаунтів зростає, вручну підтримувати таку узгодженість майже неможливо. Інструменти для багатьох акаунтів, як-от PurpleMark, прив'язують налаштування проксі, Cookie, локальне сховище й параметри відбитка до одного браузерного середовища. Під час відкриття застосовуються ті самі налаштування, що допомагає підтримувати стабільний зв'язок «один акаунт — одне середовище — один вихід» і зменшувати ризик випадкового розкриття через помилки конфігурації.
Є ще одна умова: приховування мережевого виходу не змінює правил платформи щодо ідентичності та кількості акаунтів. Ізоляція середовищ допомагає не допустити взаємного впливу акаунтів, але сама структура акаунтів усе одно має відповідати правилам платформи.
Поширені запитання
Як сайт розпізнає людину? Окрім вихідного IP запитів, сайти можуть зіставляти Cookie, відбиток браузера, WebRTC і маршрути DNS-резолвінгу, тому однієї зміни IP часто недостатньо.
Чи робить зміна IP середовище безпечним? Не обов'язково. Якщо відбиток, часовий пояс, мова й шрифти дуже схожі в кількох акаунтів, платформа все одно може пов'язати їх між собою.
Як часто перевіряти? Виконуйте перевірку щоразу після зміни мережі або проксі та після додавання нового середовища акаунта, а під час звичайної роботи періодично повторюйте її.
Зводимо все докупи
Витоки IP рідко стаються через злам пристрою. Значно частіше причина — прогалини в конфігурації: тунель не охоплює весь трафік, DNS іде іншим маршрутом, IPv6 підключається напряму, часовий пояс і мова не відповідають виходу або сторонні скрипти розкривають додаткові сигнали. Розуміння конкретного каналу витоку корисніше за запам'ятовування списку перемикачів, а узгоджений набір параметрів виходу та середовища надійніший за вимкнення одного окремого елемента.
