Грешен 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, която засяга мрежовия стек, защото всяко от двете може да върне физическия адаптер отпред.