Սխալ DNS սերվեր Windows VPN-ում՝ մետրիկ, կապման հերթականություն կամ վերջածանց
Windows-ի երեք մեխանիզմներ ընտրում են DNS լուծիչը, և նրանք տարբեր կերպ են ձախողվում։ Որոշեք ըստ անվանատարածքի ծածկույթի, գլոբալ հերթականության կամ այն բանի, թե արդյոք ուղղումը դիմանում է վերամիացմանը։
Windows հաճախորդը կարող է ունենալ աշխատող թունել, կրել կորպորատիվ լուծիչը և այնուամենայնիվ ներքին անունները ուղարկել տնային երթուղիչին։ Որ սերվերը կպատասխանի, որոշում են երեք տարբեր մեխանիզմներ, և նրանք տարբեր կերպ են ձախողվում։ Պետք չէ շտկել բոլոր երեքը. ախտանիշը ցույց է տալիս, թե որն է խաղի մեջ։ Ստորև բերված որոշման ծառը տևում է մի քանի րոպե և կանխում է սովորական արդյունքը, երբ մետրիկի փոփոխությունը, ռեեստրի վերադասավորումը և NRPT կանոնը գալու են միասին, և ոչ ոք չգիտի, թե որն ինչ արեց։
Երեք մեխանիզմ են որոշում, և սովորաբար մեկը սխալ է
Ինտերֆեյսի մետրիկը դասավորում է ադապտերները տրված հասցեների ընտանիքի համար։ Tcpip\Linkage-ի տակ գտնվող կապման հերթականությունը մեքենայի մակարդակով ինտերֆեյսի նույնացուցիչների ցանկ է, որը հին կոդային ուղիները դեռ հարցնում են։ Անվան լուծման քաղաքականության աղյուսակը (NRPT) անվանատարածքը կապում է կոնկրետ սերվերների հետ, իսկ վերջածանցների ցանկը որոշում է, թե արդյոք կարճ անունն ընդհանրապես ընդլայնվելու է։ Դրանք անկախ են, և դրա համար VPN ադապտերի ճիշտ լուծիչը պարտվում է այլ տեղի հնացած նախընտրությանը։
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-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, InterfaceMetricLAN ադապտերի վրա IPv6-ն անջատելը հեռացնում է այդ ուղին և դրա հետ՝ արձանագրությունը. IPv6 ինտերֆեյսի մետրիկի փոփոխությունը կամ կորպորատիվ անվանատարածքի NRPT կանոնը պահում է ընտանիքը և ուղղում նախընտրությունը։ Ընտրեք ավելի նեղը, եթե չեք որոշել, որ այդ կապը IPv6 չպետք է ունենա։
Ստուգեք նշված աղբյուրով, և պահեք մեկ սեփականատեր:
Ստուգեք գործիքներով, որոնք հաղորդում են, թե որ աղբյուրն է ուժի մեջ, ոչ միայն թե արդյոք էջը բեռնվում է:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type AԱպա բաժանեք զտումը ընտրությունից, որովհետև հավելվածի ներսից դրանք նույնական են երևում։ OpenVPN-ի block-outside-dns-ը արգելափակում է 53 պորտը այլ ադապտերների վրա. այն լուծիչ չի ընտրում։ Եթե հիմա ամեն հարցում ձախողվում է, զտիչը կարող է արգելափակել միակ հասանելի սերվերը. եթե կարգավորված լուծիչը անտեսվում է, հերթականությունը կամ անվանատարածքի կանոնը սխալ է։ Երկուսը միասին փոխելը արգելափակված հարցումն ու անտեսված հարցումը դարձնում է անտարբերելի։
DNS քաղաքականության համար պահեք մեկ սեփականատեր. VPN պրոֆիլը, կառավարման քաղաքականություն կամ NRPT կանոն, ոչ թե դրանցից երկուսը։ Նախքան փակելը՝
- Մղված լուծիչը պատասխանում է, երբ բացահայտ նշվում է, և սովորական որոնումն օգտագործում է այն։
- Ձեր փոխած կանոնը կամ մետրիկը ծածկում է այն հասցեների ընտանիքը, որը իրոք կրում է հարցումները։
- Կարգավորումը դիմանում է անջատմանն ու վերամիացմանը, կամ դուք այն տեղափոխել եք պահպանված պրոֆիլ։
- Ճշգրիտ մեկ մեխանիզմ է հեղինակավոր, իսկ մյուսները թողնվել են ինչպես կային։
Վերաբերվեք հերթականությանը որպես միջավայրի վիճակ, ոչ որպես ավարտվող բան։ Կրկին ստուգեք այն վերամիացումից հետո և Windows-ի թարմացումից հետո, որը դիպչում է ցանցային կույտին, որովհետև դրանցից ցանկացածը կարող է ֆիզիկական ադապտերը նորից առաջ բերել։