Поставување DNS на Windows VPN адаптер со PowerShell и поточна проверка

Windows VPN врската не ги чува DNS серверите во профилот што го уредувате во Поставки. Кога тунелот ќе се подигне, клиентот преговара за IP конфигурацијата со портата, портата испраќа список на резолвери, а Windows го применува на адаптерот на тунелот. Тој адаптер е одделен интерфејс од вашиот Wi-Fi или Ethernet, и списокот му припаѓа на интерфејсот, не на профилот. Кога ќе знаете кој објект ја поседува вредноста, препишувањето во PowerShell е една наредба; да се направи препишувањето да го преживее повторното поврзување е делот што бара одлука.

Кој објект ја поседува адресата

RAS го создава адаптерот на тунелот кога врската успева и го отстранува кога врската паѓа. DNS серверите што ги гледате во ipconfig /all доаѓаат за време на таа размена на конфигурација, покрај IPv4 и IPv6 адресите и рутите. Бидејќи вредноста е врзана за интерфејсот, Set-DnsClientServerAddress пишува во нешто што постои само додека постои врската.

Тој еден факт го објаснува најголемиот дел од забуната околу DNS-от на VPN. Профилот може да се прегледа додека сте исклучени, но нема интерфејс кон кој би се покажало, па скриптата за најава што го повикува cmdlet-от кон VPN алијасот пропаѓа пред некој да се поврзе. Го објаснува и изгледот на навидум вратена промена: ништо не е вратено, интерфејсот е уништен и повторно изграден со вредностите што ги испрати портата.

Најдете го алијасот пред да го допрете DNS-от

Името на профилот и алијасот на интерфејсот обично се истиот низа, но не се истиот објект. Get-VpnConnection ги наведува профилите; Get-NetAdapter ги наведува интерфејсите што Windows навистина ги има. DNS cmdlet-овите го сакаат вториот, и тие два се разделуваат почесто отколку што луѓето очекуваат, особено кога клиентот додава опис како "(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 обично бара подигната shell.

Самиот cmdlet е една линија, документиран во Microsoft-овата референца за Set-DnsClientServerAddress:

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

Два начина на откажување вреди да се препознаат на прв поглед. Погрешен алијас создава грешка од cmdlet-от, и тоа е добриот исход, бидејќи тишината би била полоша. Правилен cmdlet без видлив ефект обично значи дека гледате погрешен адаптер: преостанат адаптер на тунел од друг клиент, физичка мрежна карта со сличен опис, или втор виртуелен адаптер создаден од мрежна алатка во изолирана околина.

Зошто повторното поврзување може да ја поништи промената

Препишувањето припаѓа на една инстанца на интерфејсот. Кога клиентот го расклопува адаптерот и го преизградува при следното поврзување, испратените вредности се применуваат повторно и вашата листа исчезнува. Некои клиенти го пресоздаваат интерфејсот при секое поврзување; други го користат повторно за целиот век на сесијата. Споредете го индексот на интерфејсот во Get-NetAdapter помеѓу две врски и ќе знаете какво однесување имате.

Постојат три трајни одговори, а нивното натрупување создава сопствени дефекти. DNS-суфикс специфичен за врската плус NRPT правило испраќа само внатрешниот именски простор до внатрешниот резолвер и ги остава јавните имиња на мира. Поставка на групна политика или MDM применета на VPN врската поставува DNS при поврзувањето без никаква скрипта. Закажана задача што реагира на настанот на поврзување и повторно го извршува cmdlet-от е грубата опција, но работи и остава дневник. Изберете еден сопственик за DNS и запишете кој е.

Внатрешните имиња со една етикета исто така бараат список за пребарување на суфикси. Set-DnsClientGlobalSetting -SuffixSearchList важи за целата машина, па ја менува резолуцијата за секој адаптер на сметачот, вклучително Ethernet. Тестирајте го на лабораториски сметач пред да влезе во слика.

Проверете ја резолуцијата, не само поставката

Резолвер наведен на адаптер докажува само дека вредноста е запишана. Прашајте го предвидениот сервер директно, па прашајте по нормалниот пат:

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

Поделбата ви кажува каде е дефектот. Директното барање одговара, а обичното барање пропаѓа: поставката на адаптерот или списокот на суфикси не е во сила. И двете пропаѓаат: резолверот е недостапен низ тунелот, па пред повторно да го допрете DNS, погледнете ги рутите и правилата на огнениот ѕид. Директното барање пропаѓа додека обичното одговара од друго место: поделениот DNS е погрешно конфигуриран и на внатрешно име одговара јавен резолвер, што е проблем на политика пред да биде проблем на поврзување.

Стартувајте го тестот двапати, еднаш веднаш по поврзувањето и еднаш по исклучување и повторно поврзување, и споредете го излезот од Get-DnsClientServerAddress од двете извршувања. Ако испратената вредност се вратила при втората врска, препишувањето живеело и умрело со адаптерот, и само NRPT или патеката на политиката од претходниот дел ќе се задржи. Зачувајте ги двата записа и временските ознаки на поврзувањето; тие го решаваат прашањето дали останува побрзо од уште еден круг уредувања.