DNS-ը Windows VPN ադապտերում տեղադրեք PowerShell-ով, ապա ստուգեք

Windows-ի VPN կապակցումը DNS սերվերները չի պահում այն պրոֆիլում, որը խմբագրում եք Կարգավորումներում։ Երբ թունելը բարձրանում է, հաճախորդը դարպասի հետ համաձայնեցնում է IP կարգավորումը, դարպասը ուղարկում է լուծիչների ցանկ, և Windows-ը կիրառում է այն թունելի ադապտերի վրա։ Այդ ադապտերը ձեր Wi-Fi-ից կամ Ethernet-ից առանձին ինտերֆեյս է, և ցանկը պատկանում է ինտերֆեյսին, ոչ թե պրոֆիլին։ Երբ իմանաք, թե որ օբյեկտն է տիրապետում արժեքին, PowerShell-ում այն վերագրելը մեկ հրահանգ է. վերագրումը վերակապակցումից հետո պահպանելը այն մասն է, որ որոշում է պահանջում։

Որ օբյեկտն է տիրապետում հասցեին

RAS-ը ստեղծում է թունելի ադապտերը, երբ կապակցումը հաջողվում է, և հեռացնում այն, երբ կապակցումը կտրվում է։ ipconfig /all-ում ձեր տեսած DNS սերվերները գալիս են այդ կարգավորման փոխանակման ընթացքում՝ IPv4 և IPv6 հասցեների ու երթուղիների կողքին։ Քանի որ արժեքը կապված է ինտերֆեյսին, Set-DnsClientServerAddress-ը գրում է մի բանի մեջ, որը գոյություն ունի միայն այնքան, որքան կապակցումը։

Այդ մեկ փաստը բացատրում է VPN DNS-ի շուրջ եղած շփոթության մեծ մասը։ Պրոֆիլը կարելի է դիտել անջատված վիճակում, բայց ինտերֆեյս չկա, որին մատնացույց անենք, ուստի մուտքի սկրիպտը, որը 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 կանոնը միայն ներքին անվանատարածքն է ուղարկում ներքին լուծիչին և հանրային անունները հանգիստ է թողնում։ VPN կապակցման վրա կիրառված Group Policy կամ MDM կարգավորումը 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 կամ քաղաքականության երթուղին կդիմանա։ Պահպանեք երկու արձանագրությունները և կապակցման ժամանիշները. դրանք ավելի արագ են լուծում մնալու հարցը, քան խմբագրումների հերթական փուլը։