Погрешан DNS сервер у Windows VPN-у: метрика, редослед повезивања или суфикс
Три механизма Windows-а бирају DNS резолвер, и отказују различито. Одлучите по обиму именског простора, глобалном редоследу или по томе да ли поправка преживљава поновно повезивање.
Windows клијент може имати тунел који ради, носити корпоративни резолвер и ипак слати унутрашња имена кућном рутеру. Који сервер ће одговорити одлучују три различита механизма, и они отказују на различите начине. Не морате поправити сва три: симптом вам каже који је у игри. Стабло одлука испод траје неколико минута и спречава уобичајени исход, када промена метрике, преуређење регистра и NRPT правило стигну заједно и нико не зна које је од њих нешто урадило.
Три механизма одлучују, и обично је један погрешан
Метрика интерфејса поређа адаптере за дату фамилију адреса. Редослед повезивања под Tcpip\Linkage је листа идентификатора интерфејса на нивоу машине коју старије кодне путање још читају. Табела правила раздвајања имена (NRPT) везује именски простор за одређене сервере, а листа суфикса одлучује да ли се кратак назив уопште проширује. Они су независни, и зато правилан резолвер на VPN адаптеру губи од застарелог подешавања на другом месту.
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-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-а које дотиче мрежни стек, јер било које од тога може поново да стави физички адаптер напред.