Может ли оператор VPN видеть, какие сайты вы посещаете?

Спросите, что может видеть VPN, и ответ зависит от того, где вы находитесь на пути. На уровне сессии у оператора есть события аутентификации и счётчики байтов. На уровне пакетов — адреса назначения и время. На уровне DNS — возможно, сами имена. Каждый уровень отвечает на свой вопрос, и ни один переключатель не переносит вас между ними.

Определите уровень, прежде чем делать утверждение

Одно и то же соединение оставляет разные записи в каждой точке, и утверждение о приватности имеет смысл только тогда, когда называет эту точку. Читайте таблицу столбец за столбцом: что существует на этом уровне, что оператор может там увидеть и чего те же записи всё ещё не могут сказать.

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

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

Инвентаризация сессий: что хранит обычный сервер OpenVPN

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

Параметры журналирования могут добавить детали. Более высокий уровень подробности пишет больше о рукопожатии, а файл состояния может перечислить подключённых клиентов, но ни то ни другое не превращает сервер в прозрачный прокси. Для получения URL нужно завершать TLS или запускать явный прокси, и оба варианта меняют схему доверия, а не включают скрытую функцию.

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

Внутренние и внешние пакеты — разные доказательства

Запись пакетов — это способ увидеть, что действительно проходит через туннель. На сервере укажите интерфейс туннеля и пишите в файл, который можно разобрать офлайн:

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

Этот файл содержит расшифрованный внутренний трафик: адрес туннеля клиента как источник, адрес назначения и порт, размеры пакетов и время. В нём нет HTTP-пути или тела ответа, если TLS не был где-то завершён, и это чувствительные данные, хранение которых — решение политики, а не удобство отладки.

Запись на физическом интерфейсе показывает другое. Там видны внешние пакеты, адресованные конечной точке VPN, с зашифрованным содержимым внутри. Посторонние адреса в этом файле нормальны, когда есть виртуальный адаптер: туннельное устройство несёт внутренние потоки, а зашифрованный транспорт — внешние.

Спросите, на какой вопрос должна ответить запись. Использование туннеля приложением видно на виртуальном адаптере; доступность туннеля до конечной точки видна на физическом. Использование любого из файлов как полной картины даёт выводы, которых данные не поддерживают.

DNS — место, где имена становятся видимыми

DNS остаётся практическим исключением. Резолвер видит имена, которые его просят разрешить, поэтому тот, кто им управляет, узнаёт, какие сайты ищет клиент, даже когда последующие соединения зашифрованы. Запись туннеля показывает адреса; резолвер показывает имена.

Проверьте, каким адресом резолвер достиг внешнего сервиса. Ответ — это адрес выхода резолвера, и сравнение с выходом VPN говорит, прошёл ли запрос через туннель:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

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

Зашифрованный DNS перемещает видимость, а не убирает её. Сеть больше не видит запрос, но резолвер видит, и вопрос доверия просто меняет руки. Имя TLS-сервера в рукопожатии соединения — ещё один частичный сигнал: оно часто сохраняется даже тогда, когда содержимое непрозрачно, поэтому адреса назначения не единственные метаданные, которые может наблюдать пересылающий сервер.

Три типа записей и кто может их читать

Учёт сессий, записи по именам и доказательства утечки — три разных продукта с тремя разными обязательствами. Журналы сессий дешевы и малочувствительны, они отвечают, кто и когда подключился. Записи по именам требуют журналирующего резолвера или явного прокси и создают обязанность раскрытия перед затронутыми людьми. Доказательство утечки — проверка на стороне клиента, сравнивающая то, что раскрывает резолвер, с выходом туннеля.

Запишите, что из этих трёх вы ведёте, кто может это читать и сколько это хранится. Утверждения, что сервис не ведёт журналов, описывают один уровень и остаются верными только в этих пределах. Один и тот же провайдер может быть точен насчёт сессий и ошибаться насчёт DNS.

Держите проверку воспроизводимой: тот же запрос к резолверу, тот же интерфейс записи и то же сравнение. Утверждение о приватности, которое нельзя проверить на названном уровне, — это лозунг, а не операционный факт.