Утечка DNS через VPN в Windows: почему метрика важнее маршрута

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

Два объяснения одной утечки

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

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

Сравните метрики и резолверы вместе

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

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

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

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

Поднимите туннель и проверьте снова

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

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

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

Затем запросите одно внутреннее и одно публичное имя и проверьте, какой сервер ответил. Справочник Microsoft документация по автоматическим метрикам объясняет, почему предпочитается наименьшее значение и как выводится автоматическое назначение.

Сделайте так, чтобы это пережило переподключение

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

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