Ваш VPN шифрует DNS или только следующий участок пути?

Включение зашифрованного DNS на сервере VPN часто описывают как закрытие утечки, и это описание скрывает, какое соединение изменилось. Участок от клиента до резолвера и участок от резолвера до вышестоящего узла — это разные соединения с разными владельцами. Шифрование одного оставляет другое точно таким, каким оно было.

Запишите, кто получает запрос на каждом этапе, прежде чем трогать файл конфигурации.

Две схемы выглядят одинаково на странице настроек

В первой схеме устройство само запускает DNS over TLS, а туннель просто переносит это соединение к выбранному вами резолверу. Сеанс TLS завершается на резолвере, то есть резолвер видит запрос, а выход VPN видит зашифрованный текст, который не может прочитать. Во второй схеме устройство отправляет обычный DNS через туннель на форвардер на хосте VPN, и этот форвардер открывает собственное зашифрованное соединение с вышестоящим резолвером. В списке функций обе выглядят как "зашифрованный DNS с VPN", но читаемый запрос они помещают в разные здания.

Разница измерима, а не философская. Найдите сеанс TLS на клиенте или на сервере и узнаете, какая схема у вас на самом деле.

Составьте карту цепочки резолверов до её изменения

Сосчитайте резолверы на пути и назовите роль каждого. Компонент пересылки передаёт запрос другому резолверу, а рекурсивный резолвер выполняет работу по поиску ответа и может напрямую общаться с авторитетными серверами. Эти роли определены отдельно именно по этой причине, и определения резолверов из RFC 9076 стоит прочитать, прежде чем предполагать, что вышестоящий адресат только один. Хост, запускающий собственный рекурсивный резолвер, не имеет единственного "вышестоящего узла" для шифрования, что делает весь план недействительным.

Затем спросите, какой компонент настроен использовать клиент. DNS-адрес, выдаваемый профилем VPN, сообщает, куда идут запросы, а не какой процесс на них отвечает.

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

Проверьте, какой участок зашифрован

Начните с клиента и убедитесь, есть ли у него сеанс TLS на порт 853. Запрос, который правильно разрешается через порт 53, ничего не доказывает о шифровании.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Затем перейдите на хост VPN и поищите исходящее зашифрованное соединение, открытое форвардером. Таблица сокетов покажет, существует ли вышестоящий сеанс TLS и какой процесс им владеет:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Если клиент показывает сеанс TLS, а сервер нет, вы в первой схеме, и сервер не может читать запросы, которые пересылает на уровне IP. Если сервер показывает сеанс TLS, а клиент обычный трафик порта 53 внутри туннеля, вы во второй схеме: следующий участок защищён, а форвардер по-прежнему читает каждое имя, которое запрашивает устройство. Второй результат не является сбоем, но называть его сквозным шифрованием неправильно.

Запишите владельца и поведение при сбое

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

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

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