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