Задаване на DNS на VPN адаптер в Windows с 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 или пътят по политика от предишния раздел ще удържи. Запазете двата записа и часовите марки на свързване; те решават въпроса дали се задържа по-бързо от още един кръг редакции.