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 подвёл.

Если прямое соединение действительно есть, рассматривайте это как находку о сетевом пути. Исследуйте маршрутизацию, разделённый туннель и политику клиента на их собственных условиях и не смешивайте этот результат со значением нагрузки, которое просто пережило переподключение. Две неисправности выглядят одинаково на скриншоте и ведут себя совершенно по-разному в захвате.