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

Три механізми Windows вибирають розв'язувач DNS, і вони відмовляють по-різному. Вирішуйте за обсягом простору імен, глобальним порядком або тим, чи переживає виправлення перепідключення.

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

Три механізми вирішують, і зазвичай один неправильний

Метрика інтерфейсу впорядковує адаптери для заданої родини адрес. Порядок прив'язки в розділі Tcpip\Linkage — це загальносистемний список ідентифікаторів інтерфейсів, до якого старі шляхи коду все ще звертаються. Таблиця політики розв'язання імен (NRPT) прив'язує простір імен до конкретних серверів, а список суфіксів вирішує, чи коротке ім'я взагалі розкривається. Вони незалежні, і тому правильний розв'язувач на адаптері VPN програє застарілій перевазі в іншому місці.

What you seeMechanism to checkFirst command
Every name is slow, public names sometimes wrongGlobal adapter order: metric, then LinkageGet-NetIPInterface
Internal names resolve to a public addressThe query left through the home resolver, not the tunnelResolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10
Only corp.example names fail, public names fineNamespace binding: NRPT or suffixGet-DnsClientNrptRule
Short name fails, fully qualified name worksSuffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the serverGet-DnsClientGlobalSetting
Works, then breaks after a reconnectRuntime setting that was never persistedGet-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect

Жоден із цих механізмів не є тим боком тунелю. Якщо сервер, який просуває 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, що торкається мережевого стека, бо кожне з цього може знову висунути фізичний адаптер уперед.

Схожі статті