Что локальная сеть всё ещё видит через ваш VPN

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

Утверждение первое: никто не может прочитать трафик

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

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

В macOS этот конвейер выводит по одной строке субъекта для каждого сертификата в связке ключей машины, не открывая окно, а в Windows certutil -store Root перечисляет то же хранилище, которое certlm.msc показывает графически. Корень, принадлежащий школе, работодателю или продукту сетевой безопасности, — это запись, которую стоит искать. Найти один доказывает лишь то, что перехват возможен, а не то, что он происходит.

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

Утверждение второе: никто не видит, куда вы идёте

Пункт назначения — более трудное утверждение, потому что две утечки происходят до загрузки страницы. Запрос уходит к тому резолверу, который настроен в системе, и ответ виден сети, которая его несёт. Затем рукопожатие TLS передаёт запрошенное имя сервера открытым текстом, если Encrypted Client Hello не поддерживается на обоих концах. Ни одна из утечек не требует расшифровки, поэтому туннель не влияет ни на одну из них.

resolvectl status | grep -A2 "Link"
nslookup example.com

Какой резолвер действительно используется, определяет уязвимость, и это можно измерить, а не обсуждать. В Linux resolvectl status выводит DNS-серверы для каждого соединения, и его вывод сообщает, отвечает резолвер сайта или навязанный. Windows отвечает на тот же вопрос с помощью nslookup example.com, первый блок вывода которого — ответивший DNS-сервер.

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

Утверждение третье: никто не знает, что вы подключились

Третье утверждение — то, которое туннель не может обеспечить, потому что пакеты всё ещё пересекают локальную сеть. Эта сеть узнаёт адрес оконечной точки, примерный объём, время и существование одного долгоживущего зашифрованного сеанса, чего достаточно, чтобы блокировать, ограничивать или просто замечать. Межсетевой экран, который не может прочитать пакет, всё равно может отказаться его пропустить. Быть под наблюдением не то же самое, что не быть под наблюдением никого: вы переместили наблюдателя, а не удалили его.

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

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

Решите, какое утверждение вам нужно

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

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