Куда уходит DNS, когда вы сочетаете Tor и VPN

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

Назовите каждый обмен, прежде чем называть это утечкой

Первый обмен разрешает сам конечный пункт VPN и происходит до того, как появляется какая-либо защита. Второй разрешает место назначения для Tor Browser, который может передать имя прокси, вместо того чтобы разрешать его локально. Третий охватывает всё остальное на машине, включая проверки обновлений, почтовые клиенты и собственные служебные запросы операционной системы. Только первый из них может произойти без участия двух других.

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

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

Запрос при запуске происходит до туннеля

Клиент, настроенный с именем хоста, должен разрешить это имя, чтобы открыть туннель, и в этот момент туннеля, который мог бы понести запрос, ещё нет. Отвечает любой резолвер, который операционная система предлагает в текущей сети, — это может быть captive portal, гостиничный резолвер или публичный. Это не утечка в туннеле, потому что туннеля ещё нет.

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

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

Браузер и остальная часть машины различаются

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

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

Проверяйте программу, которая сделала запрос, а не экстраполируйте с одной тестовой страницы. Разница между запросом, который несётся внутри туннеля, и тем, который никогда не дошёл до Tor, — это ровно та разница, которую один адрес резолвера показать не может.

Проверьте каждую программу, затем сравните с намерением

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

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

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

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