Няправільны 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, якое закранае сеткавы стек, бо любое з гэтага можа зноў паставіць фізічны адаптар наперад.

Падобныя артыкулы