VPN не видав вашу стару IP: це зробило запам'ятоване значення

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

Два пояснення однієї адреси

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

Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1

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

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

Пам'ять програми переживає повторне підключення

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

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

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

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

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

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

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

Зберігання — це інший етап, ніж передавання

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

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

Що перевірити, перш ніж звинувачувати тунель

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

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