Что ваш провайдер всё ещё видит, когда вы качаете торренты через VPN

Пройдите вопросы по порядку: что может наблюдать сеть доступа, что выходит из туннеля без неё, что раскрывает поиск имён и что всё равно узнают пиры и трекеры. Каждый ответ не зависит от остальных, и VPN полностью решает только первый. Четвёртый — это место, где большинство ожиданий тихо рушится, потому что никакой туннель не убирает имя учётной записи.

Начните с решения, какой наблюдатель вас беспокоит, потому что ответ меняется вместе с наблюдателем.

Одно соединение заменяет многие

Когда клиент действительно находится внутри туннеля, сеть доступа видит одно постоянное зашифрованное соединение с одним адресом VPN. Объём, время и сам факт использования VPN остаются видимыми; имена хостов трекеров, адреса пиров и имена файлов — нет. Это реальное улучшение, и более узкое, чем подразумевает маркетинг. Оператор туннеля сидит посередине и видит больше, чем сеть доступа.

Заявление об отсутствии журналов описывает политику хранения, а не техническую видимость. Это разные утверждения, и только первое провайдер может обещать.

Утечка идёт от привязки, а не от туннеля

BitTorrent создаёт поток короткоживущих соединений TCP и UDP к пирам, трекерам, узлам DHT и локальному обнаружению. Привяжите клиент к физическому адаптеру или перезапустите его после падения туннеля, и полученный трафик будет ровно тем, ради чего туннель и существовал. Правила брандмауэра — более слабый контроль, чем кажется: правило, совпадающее только с маршрутом по умолчанию, только с IPv4 или только с новыми соединениями, оставляет пути открытыми. Привязка клиента к интерфейсу туннеля и проверка этой привязки — более сильный шаблон.

Проверьте, намеренно остановив туннель и наблюдая, прекращаются ли передачи. Если они продолжаются, клиент никогда не был внутри. Повторите после перезапуска клиента и после пробуждения ноутбука, потому что именно тогда привязки обычно теряются.

DNS называет сайт, не касаясь передачи

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

Имя, разрешаемое через туннель, и передача, уважающая привязку, — отдельные свойства, и каждое может отказать само по себе.

Рой и трекер видят разное

Обмен адресами — часть протокола, поэтому пиры записывают то, что видят. Подключение с выхода даёт им выход; прямое подключение даёт домашний адрес. DHT и обмен пирами распространяют это наблюдение дальше, и более поздняя сессия без туннеля может связать тот же порт клиента и версию. Трекер может знать ещё больше: ключ доступа в URL объявления идентифицирует учётную запись независимо от того, с какого выхода пришли пакеты.

Шифрование снова закрывает другую ось. HTTPS защищает запрос начиная с выхода; обычный HTTP показывает строку запроса каждой сети на пути, и поэтому один протокол можно формировать, а другой нет.

Ответьте на четыре вопроса доказательствами, а не значком. Значок лишь сообщает, что туннель существует.