DNS в VPN против DoH в браузере: что не покажет тест на утечку

Страница теста на утечку говорит, что с вашим DNS всё в порядке, значок браузера — что безопасно, а внутренняя вики всё равно не загружается. Все три утверждения могут быть верны одновременно, потому что адрес резолвера — это не то же самое, что политика, выбравшая его, или путь, который прошёл запрос. То, что люди называют утечкой DNS, на самом деле один вопрос: какой резолвер получил имя и был ли этот выбор намеренным? Чтобы разобраться, нужны три проверки, и только последняя включает изменение настройки.

Миф первый: значок называет ваш резолвер

Тест на утечку разрешает пробное имя и сообщает адрес, который ответил. Он не сообщает политику, выбравшую этот резолвер, а когда запрос обёрнут в DNS поверх HTTPS, промежуточное устройство на пути вообще не видит имя. Две совершенно разные машины дают один и тот же успокаивающий значок: одна, где VPN протолкнул 10.8.0.1 и браузер им пользуется, и другая, где браузер проигнорировал системный список и отправил имя через туннель своему собственному шифрованному провайдеру.

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

Миф второй: браузер покидает туннель

DNS выбирает адрес, маршрутизация несёт соединение, и это два отдельных уровня. Запрос к публичному провайдеру DoH — это по-прежнему TCP порт 443 к маршрутизируемому адресу. Если ваша таблица маршрутов отправляет маршрут по умолчанию в туннель, этот запрос тоже идёт через туннель. Бренд резолвера не определяет путь.

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

Миф третий: каждый VPN перекрывает каждый браузер

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

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

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

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

У решения три входа, а не один

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

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

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

Проверьте политику, которую, как вам кажется, вы настроили

Проверяйте по имени, а не по значку. Разрешите публичное имя и приватное имя через системный резолвер, затем повторите внутри браузера с его собственной настройкой безопасного DNS в том режиме, который собираетесь использовать. Если приватное имя не разрешается только в браузере, вы нашли несовпадение получателя, не тронув ни одной настройки VPN.

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

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