Частный DNS против VPN: что на самом деле охватывает каждый уровень
Проследите один запрос от экрана частного DNS до туннеля: что видит каждый уровень, где эти два расходятся и почему внутренние имена — то место, где всё ломается.
На вашем телефоне частный DNS настроен на имя хоста провайдера и одновременно работает приложение VPN. Разумно предположить, что теперь за поиск имён отвечает одно из них. Ни то ни другое не делает этого в том смысле, который подразумевает эта фраза, и самый быстрый способ увидеть почему — проследить один запрос с момента, когда вы нажимаете на ссылку.
Эти две функции находятся в разных точках одного путешествия. Частный DNS шифрует вопрос, который вы задаёте резолверу. VPN меняет маршрут, по которому идёт соединение с ответом.
Поэтому пройдите это по порядку на устройстве, где включено и то и другое, и отметьте, что ещё может видеть каждый уровень.
Шаг первый: поиск покидает приложение
Вы нажимаете на ссылку. Прежде чем что-либо подключится, приложению нужен адрес для этого имени хоста. В Android нужный экран — Настройки, Сеть и интернет, Частный DNS. Если выбрать Имя хоста провайдера частного DNS, устройство переходит в строгий режим: оно выполняет DNS поверх TLS к этому имени хоста на порту 853, и если зашифрованный обмен не удаётся, поиск завершается неудачей, а не тихо откатывается к открытому тексту на порту 53.
Это существенное отличие от Автоматически, где используется оппортунистическое шифрование и при вмешательстве сети охотно применяется незашифрованный резолвер. Если ваша цель — чтобы поиски никогда не шли в открытом виде, строгий режим с именем хоста провайдера и есть подходящая настройка.
Вот первое, что выявляет этот проход: поиск защищён от локальной сети, а резолвер всё равно узнаёт имя. Шифрование покрывает только переход. Оператор этого резолвера видит запрос, потому что отвечать на него — его работа.
Шаг второй: соединение идёт другим маршрутом
Резолвер возвращает адрес, и приложение подключается к нему. На этот шаг не влияет то, как был зашифрован поиск. Без туннеля соединение выходит с вашего обычного публичного адреса, и IP назначения вместе с рукопожатием TLS обычно всё равно делают имя хоста видимым для сети, с зашифрованным DNS или без него.
Включите VPN, и меняется именно этот шаг. Трафик, соответствующий политике маршрутизации клиента, идёт через туннель, локальная сеть видит соединение с точкой входа VPN, а сайт обычно видит выходной адрес. Разрешение имён тоже может идти внутри туннеля — в зависимости от того, что передаёт клиент.
Это разделение и есть всё сравнение в одном предложении. Шифрование DNS отвечает на вопрос, кто может прочитать вопрос. VPN отвечает на вопрос, куда идёт разговор.
Шаг третий: внутри туннеля DNS становится вопросом политики
Теперь две функции взаимодействуют, и браузер — обычный источник сюрпризов. Браузер с собственной настройкой безопасного DNS может отправлять поиски выбранному им резолверу по HTTPS, вместо того чтобы спрашивать операционную систему. Настройка частного DNS в Android в это решение не проникает.
В Firefox переключатель находится в разделе Настройки, Приватность и защита, Включить безопасный DNS. В Chrome — в разделе Настройки, Конфиденциальность и безопасность, Использовать безопасный DNS. Оба можно привязать к конкретному провайдеру или оставить выключенными, и когда они включены, конфигурация DNS туннеля обходится для этих поисков, хотя трафик страницы по-прежнему идёт через туннель.
Если VPN передаёт свой резолвер, а браузер настаивает на своём, получается разрыв: имена разрешаются, страницы загружаются, а поиски, которые должны были идти через туннель, ушли напрямую. Адрес резолвера, отличный от точки входа VPN, сам по себе не доказательство утечки, но путь поиска, противоречащий заявленному намерению, стоит исправить.
Шаг четвёртый: внутренние имена — то место, где всё ломается
Подключитесь к рабочему VPN и откройте внутренний хост. Если безопасный DNS браузера включён и указывает на публичный резолвер, для браузера такого имени не существует. Туннель поднят, всё остальное работает, а одно имя хоста завершается ошибкой, которая выглядит как недоступный сайт.
Та же поломка проявляется наоборот в Android. Строгий частный DNS с публичным провайдером не разрешит имена, которые знает только внутренний резолвер, а у строгого режима нет запасного пути. Разделять DNS телефона между публичным зашифрованным резолвером и корпоративным резолвером — это не настройка, а вопрос политики маршрутизации, на который должен ответить тот, кто управляет VPN.
Проверьте это, прежде чем винить туннель: запросите внутреннее имя, а затем то же имя с отключённым безопасным DNS браузера. Если оно разрешается, проблема была в выборе резолвера, а не в соединении.
Что этот проход велит вам изменить
Четыре экрана несут почти всё. Посмотрите их в этом порядке и запишите, что говорит каждый, потому что ответ обычно виден в сочетании:
- Настройки Android, Сеть и интернет, Частный DNS: Автоматически или имя хоста провайдера, и какое именно имя.
- Настройка безопасного DNS браузера: выключена или привязана к конкретному резолверу.
- Политика DNS клиента VPN: передаёт ли он резолвер и исключает ли раздельный туннель что-то, чему всё ещё нужны имена?
- Проверка внутреннего имени хоста при поднятом туннеле, выполненная дважды: один раз с включённым DNS браузера, один раз с выключенным.
Затем сопоставьте исправление с требованием, а не наоборот. Если требование в том, чтобы поиски уходили зашифрованными и попадали к выбранному вами резолверу, настройте строгий частный DNS и добейтесь согласия браузера. Если требование в том, чтобы трафик выходил в другом месте, настройте туннель и перестаньте ждать, что настройка DNS переместит ваш адрес.
И держите в поле зрения ограничения. Ни одна из функций не делает враждебный адресат безопасным, и ни одна не убирает личность, под которой вы вошли. Шифрование меняет, кто может прочитать вопрос; туннель меняет, куда идёт соединение; ни то ни другое не анонимизирует учётную запись.