Неверный DNS-сервер в Windows VPN: метрика, порядок привязки или суффикс

Клиент Windows может иметь работающий туннель, нести корпоративный распознаватель и всё равно отправлять внутренние имена на домашний маршрутизатор. Какой сервер ответит, решают три разных механизма, и они отказывают по-разному. Не нужно исправлять все три: симптом подсказывает, какой из них в игре. Дерево решений ниже занимает несколько минут и предотвращает обычный исход, когда изменение метрики, переупорядочивание реестра и правило NRPT появляются вместе и никто не знает, что из этого сработало.

Три механизма решают, и обычно один неверен

Метрика интерфейса упорядочивает адаптеры для заданного семейства адресов. Порядок привязки в разделе Tcpip\Linkage — это общесистемный список идентификаторов интерфейсов, к которому старые ветки кода всё ещё обращаются. Таблица политики разрешения имён (NRPT) привязывает пространство имён к конкретным серверам, а список суффиксов решает, будет ли короткое имя вообще раскрыто. Они независимы, и поэтому правильный распознаватель на адаптере VPN проигрывает устаревшему предпочтению в другом месте.

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

Решение первое: может ли продвинутый распознаватель вообще ответить?

Спросите сервер явно и сравните с обычным запросом. Разрыв между ответами отделяет проблему выбора от проблемы доступности, и здесь это самая быстрая развилка:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Если первый удаётся, а второй нет, распознаватель доступен и Windows выбирает плохо; перейдите к решениям о пространстве имён и порядке ниже. Если и первый не удаётся, ничто на клиенте не поможет: проверьте, доходят ли UDP и TCP 53 до сервера через туннель, не отбрасывает ли пул хост-межсетевой экран на сервере и здоровы ли собственные пересыльщики сервера.

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

Решение второе: одно пространство имён или каждый запрос?

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

Задайте метрику для каждого семейства адресов, на обоих интерфейсах, и затем подтвердите порядок:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Замените 11 на ifIndex адаптера туннеля из строки выше; если 11 — это адаптер LAN, та же команда понизит неверный путь. Повышение адаптера LAN достигает того же порядка с другой стороны: netsh int ip set interface interface="Ethernet" metric=15, и netsh int ipv6 set interface interface="Ethernet" metric=15 для второго семейства, потому что int ip затрагивает только IPv4.

Порядок привязки — последнее средство, а не первый шаг. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage содержит список Bind идентификаторов устройств, и перенос идентификатора туннеля вперёд действительно меняет то, к какому адаптеру обращаются первым, но это общесистемное значение реестра без области действия по пространству имён. Экспортируйте его перед правкой и затем переподключите туннель, чтобы порядок действовал в том состоянии, которого ждёт клиент.

Для одного пространства имён предпочитайте более узкий инструмент:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Решение третье: переживает ли исправление переподключение?

Метрика, работающая до следующего переподключения по коммутируемой линии, никогда не сохранялась. L2TP/IPsec и другие профили соединения создаются заново при запуске соединения, поэтому сохранённое значение живёт в записи телефонной книги как IpInterfaceMetric, а не только на живом интерфейсе. Некоторые среды скриптуют это поле именно по этой причине; другие продвигают предпочтение из политики управления и оставляют конечную точку в покое.

Кэш и регистрация — отдельный слой. Их запуск после поднятия туннеля исправляет устаревшие записи и перерегистрирует клиента, но ни то ни другое не переупорядочивает адаптер:

ipconfig /registerdns
ipconfig /flushdns

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

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

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

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

Проверяйте с названным источником и держите одного владельца

Проверяйте инструментами, которые сообщают, какой источник действует, а не только загружается ли страница:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Затем отделите фильтрацию от выбора, потому что изнутри приложения они выглядят одинаково. block-outside-dns в OpenVPN блокирует порт 53 на других адаптерах; он не выбирает распознаватель. Если теперь отказывает каждый запрос, фильтр может блокировать единственный доступный сервер; если настроенный распознаватель игнорируется, неверен порядок или правило пространства имён. Изменение обоих сразу делает заблокированный запрос и проигнорированный запрос неразличимыми.

Держите одного владельца политики DNS: профиль VPN, политику управления или правило NRPT, а не два из них. Прежде чем закрыть вопрос:

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

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