Наладзіць DNS на адаптары VPN Windows праз PowerShell і праверыць

Windows прывязвае DNS тунеля да адаптара, а не да профілю VPN. Наладзьце яго пасля падключэння ў PowerShell, затым праверце, ці захоўвае яго перападключэнне.

Падключэнне VPN у Windows не захоўвае DNS-серверы ў профілі, які вы рэдагуеце ў Наладах. Калі тунель узнікае, кліент узгадняе IP-канфігурацыю з шлюзам, шлюз перадае спіс рэзалвераў, і Windows прымяняе яго да адаптара тунеля. Гэты адаптар — асобны інтэрфейс ад вашага Wi-Fi або Ethernet, і спіс належыць інтэрфейсу, а не профілю. Калі вы ведаеце, які аб'ект валодае значэннем, перакрыццё яго ў PowerShell — адна каманда; зрабіць так, каб перакрыццё перажыло перападключэнне, — гэта частка, якая патрабуе рашэння.

Які аб'ект валодае адрасам

RAS стварае адаптар тунеля, калі падключэнне паспяховае, і выдаляе яго, калі падключэнне зрываецца. DNS-серверы, якія вы бачыце ў ipconfig /all прыходзяць падчас гэтага абмену канфігурацыяй, побач з адрасамі IPv4 і IPv6 і маршрутамі. Паколькі значэнне прывязана да інтэрфейсу, Set-DnsClientServerAddress запісвае ў нешта, што існуе толькі пакуль існуе падключэнне.

Гэты адзін факт тлумачыць большую частку блытаніны вакол DNS у VPN. Профіль можна агледзець у адключаным стане, але няма інтэрфейсу, на які можна паказаць, таму сцэнар уваходу, які выклікае каманду супраць псеўданіма VPN, церпіць няўдачу да таго, як хто-небудзь падключыўся. Ён таксама тлумачыць змену, якая выглядае як адкат: нічога не адкочвалася, інтэрфейс быў знішчаны і пераствораны са значэннямі, якія перадаў шлюз.

Знайдзіце псеўданім, перш чым кранаць DNS

Імя профілю і псеўданім інтэрфейсу звычайна адзін радок, але гэта не адзін аб'ект. Get-VpnConnection пералічвае профілі; Get-NetAdapter пералічвае інтэрфейсы, якія Windows мае насамрэч. Каманды DNS хочуць другі, і яны разыходзяцца часцей, чым людзі чакаюць, асабліва калі кліент дадае да імя адаптара апісальнік накшталт "(RAS)".

Калі профілю няма, PowerShell можа стварыць уласны запіс. Тып тунеля і аўтэнтыфікацыя павінны адпавядаць таму, што прапануе шлюз, бо неадпаведнасць выяўляецца ў момант падключэння, а не ў момант стварэння:

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

Падключыцеся адзін раз, затым прачытайце сапраўдны псеўданім, перш чым пісаць любую каманду DNS:

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

Ужывіце перакрыццё ў правільным парадку

Парадак важнейшы за сінтаксіс. Адаптар павінен быць уключаны, псеўданім павінен вырашацца, а ўліковы запіс павінен мець дазвол змяняць налады інтэрфейсу. Падключэнне на карыстальніка звычайна прымае змену ад увайшоўшага карыстальніка; падключэнне на ўсіх карыстальнікаў, створанае з -AllUserConnection , звычайна патрабуе падвышанай абалонкі.

Сама каманда — гэта адзін радок, дакументаваны ў даведцы Set-DnsClientServerAddress:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

Два рэжымы няўдачы варта пазнаваць з выгляду. Няправільны псеўданім выдае памылку каманды, і гэта добры вынік, бо маўчанне было б горш. Правільная каманда без бачнага эфекту звычайна азначае, што вы глядзіце на няправільны адаптар: пакінуты адаптар тунеля ад іншага кліента, фізічны NIC з падобным апісаннем або другі віртуальны адаптар, створаны інструментам сеткавай ізаляцыі.

Чаму перападключэнне можа адмяніць змену

Перакрыццё належыць аднаму асобніку інтэрфейсу. Калі кліент разбірае адаптар і перабудоўвае яго пры наступным падключэнні, перададзеныя значэнні прымяняюцца зноў, і ваш спіс знікае. Некаторыя кліенты пераствараюць інтэрфейс пры кожным падключэнні; іншыя выкарыстоўваюць яго ўвесь час сеансу. Параўнайце індэкс інтэрфейсу ў Get-NetAdapter паміж двума падключэннямі, і вы даведаецеся, якія паводзіны ў вас.

Існуюць тры трывалыя адказы, і іх накладанне стварае ўласныя памылкі. Суфікс DNS для канкрэтнага падключэння плюс правіла NRPT адпраўляе ўнутранае прастору імёнаў толькі ўнутранаму рэзалверу і пакідае публічныя імёны спакою. Налада Group Policy або MDM, ужытая да падключэння VPN, задае DNS у момант падключэння без якога-небудзь сцэнару. Запланаваная задача, якая рэагуе на падзею падключэння і перазапускае каманду, — грубы варыянт, але ён працуе і пакідае журнал. Выберыце аднаго ўладальніка DNS і запішыце, хто гэта.

Унутраныя імёны з адной меткай таксама патрабуюць спісу пошуку суфіксаў. Set-DnsClientGlobalSetting -SuffixSearchList дзейнічае на ўсёй машыне, таму змяняе вырашэнне для кожнага адаптара на машыне, уключаючы Ethernet. Праверце гэта на лабараторнай машыне, перш чым яно трапіць у вобраз.

Правярайце вырашэнне, а не толькі наладу

Рэзалвер, пералічаны на адаптары, даказвае толькі, што значэнне запісана. Спытайцеся ў патрэбнага сервера напрамую, затым спытайцеся звычайным шляхам:

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

Раздваенне паказвае, дзе знаходзіцца збой. Прамы запыт адказвае, а звычайны запыт церпіць няўдачу: налада адаптара або спіс суфіксаў не дзейнічае. Абодва церпяць няўдачу: рэзалвер недасяжны праз тунель, таму паглядзіце на маршруты і правілы фільтра перад тым, як зноў кранаць DNS. Прамы запыт церпіць няўдачу, а звычайны запыт адказвае аднекуль: split DNS наладжаны няслушна, і ўнутранае імя адказвае публічны рэзалвер, што з'яўляецца праблемай палітыкі раней, чым праблемай злучэння.

Правядзіце тэст двойчы, адзін раз адразу пасля падключэння і адзін раз пасля адключэння і перападключэння, і параўнайце Get-DnsClientServerAddress вывад абодвух прагонаў. Калі перададзенае значэнне вярнулася ў другім падключэнні, перакрыццё жыло і памерла разам з адаптарам, і ўтрымае яго толькі маршрут NRPT або палітыкі з папярэдняга раздзела. Захавайце абодва транскрыпты і пазнакі часу падключэння; яны вырашаюць пытанне, ці трымаецца яно, хутчэй за чарговы раунд правак.

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