Հանրային DNS-ի աշխատանքը չի նշանակում, որ Active Directory-ն հասանելի է

VPN-ը միանում է, զննարկիչը բացում է հանրային կայք, և դյուրակիր համակարգիչը դեռ չի կարողանում մուտք գործել դոմեն։ Սովորական եզրակացությունը այն է, որ DNS-ը կարգին է, քանի որ անունները լուծվում են։ Այն կարգին չէ, և պատճառը նրանում է, որ զննարկիչի ստուգումը փորձարկում է միայն մեկ հարցում այն շղթայից, որն անհրաժեշտ է դոմենին միացված հաճախորդին։ Դոմենի հայտնաբերումը նախ հարցնում է ծառայության գրառումները, ապա այդ գրառումներում նշված կարգավորիչների հասցեները, ապա երթուղի դեպի այն պորտերը, որոնց վրա լսում են այդ կարգավորիչները։ Հանրային պատասխանը չի բավարարում այդ քայլերից ոչ մեկը։

Առասպելը՝ անունները լուծվում են, ուրեմն DNS-ը վերջացած է

Հանրային կայքի լուծումը միայն ասում է, որ ինչ-որ լուծիչ պատասխանել է հանրային գոտու անվան համար մեկ A կամ AAAA հարցման։ Active Directory-ն օգտագործում է նույն արձանագրությունը այլ հարցի համար՝ որտեղ են դոմենի ծառայությունները, և որ կարգավորիչը պետք է օգտագործի այս հաճախորդը։ Հարցն արտահայտվում է որպես SRV գրառումներ դոմենի անունով կոչված գոտու տակ, և ռեկուրսիվ հանրային լուծիչը պատճառ չունի դրանք պահելու։

Երբ գրառումը բացակայում է, լուծիչը վերադարձնում է բացասական պատասխան, որը վավեր DNS պատասխան է, այլ ոչ թե ընդհատում։ Այնուհետև հաճախորդը անցնում է քեշավորված կարգավորիչի տեղեկատվությանը, եթե ունի, և հենց դրա համար է, որ աշխատասեղանը կարող է ժամերով լավ երևալ և ձախողվել վերագործարկումից կամ գաղտնաբառի փոփոխությունից հետո։

Ինչ է իրականում հարցնում դոմենի հաճախորդը՝ հերթականությամբ

corp.example-ի նման դոմենի համար ընդհանուր տեղորոշիչ հարցումը _ldap._tcp.dc._msdcs.corp.example-ն է։ SRV պատասխանները նշում են թեկնածու կարգավորիչներին և նրանց պորտերը, ապա հաճախորդին անհրաժեշտ են հասցեի գրառումներ այդ հոսթային անունների համար՝ նախքան կապ բացելը։ Տեղամասին տեղյակ հայտնաբերումը հարցումներ է ավելացնում տեղամասի ենթադոմենի տակ, և պատասխանները որոշում են, թե որ կարգավորիչներն են նախընտրելի, և ոչ թե որը պարտադիր է։

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Հետևեք շղթային այդ հերթականությամբ՝ այն ցանցից, որտեղ խնդիրն առաջանում է։ Հասցեին անհասանելի լուծվող հոսթային անունը երթուղավորման խափանում է, ոչ DNS խափանում։ Հասանելի կարգավորիչը, որի տեղորոշիչ գրառումները բացակայում են, DNS խափանում է, ոչ երթուղավորման խափանում։ Երկուսն էլ առաջացնում են նմանատիպ օգտվողական բողոքներ և բոլորովին տարբեր վերանորոգումներ։

Ինչու հանրային լուծիչը պատասխանում է, և մուտքը դեռ կտրվում է

Եթե ադապտերը հաճախորդին տալիս է հանրային լուծիչ, հանրային անունները աշխատում են, իսկ ներքին անվանատարածքը՝ ոչ։ Երկրորդ հանրային լուծիչ ավելացնելը չի օգնում, որովհետև նրանցից ոչ մեկը չի պահում գոտին։ Նաև սովորական «նախ ներքին, հետո հանրային» ցանկը չի վարվում որպես յուրաքանչյուր դոմենի կանոն՝ առաջին սերվերի բացասական պատասխանը օրինական պատասխան է, և հաճախորդը չի կրկնում երկրորդ սերվերը միայն այն պատճառով, որ պատասխանը դատարկ էր։

Երկու ներքին լուծիչները, եթե երկուսն եք աշխատեցնում, պետք է պահեն AD անվանատարածքը և հասանելի լինեն հաճախորդի ընթացիկ ցանցից։ Հենց այս մասն են կոտրում բաժանված թունելի նախագծերը՝ VPN-ը կարող է կրել թունելի ենթացանցը, մինչ ներքին լուծիչը գտնվում է նախածանցի վրա, որը թունելը չի երթուղավորում, ուստի հարցումը դուրս է գնում լուծիչի, որը չի կարող պատասխանել դրան։

Windows-ը կիրառում է նաև անունների լուծման քաղաքականություն, որը կարող է որոշակի անվանատարածքներ ուղղել որոշակի սերվերների, և ադապտերի ցուցադրած DNS հասցեները ամբողջ պատմությունը չեն։ Ադապտերի ցանկը փոխելը առանց այդ քաղաքականությունը փոխելու կարող է թողնել արդյունավետ կարգավորումը անփոփոխ, և դրա համար է, որ կիրառված թվացող ուղղումը ոչ մի ազդեցություն չի ունենում։

Պահեք թունելի DNS-ը և նրա երթուղիները համաձայնեցված

VPN պրոֆիլը, որը հրում է լուծիչ, բայց ոչ այն պարունակող նախածանցը, ստեղծում է լուծիչ, որին հաճախորդը չի կարող հասնել. մեկը, որը հրում է նախածանցը առանց լուծիչի, թողնում է հաճախորդին հարցնել տեղականին։ Վերաբերվեք զույգին որպես մեկ կարգավորման միավոր և ստուգեք երկուսն էլ յուրաքանչյուր պրոֆիլի փոփոխությունից հետո, որովհետև վերադասավորված հրումը կամ նոր բաժանված թունելի քաղաքականությունը կարող է բաժանել նրանց։

Ստուգեք նաև, թե հաճախորդն ինչ է անում հրված պարամետրի հետ։ Որոշ հաճախորդներ DNS սերվերը կիրառում են միայն թունելի միջերեսի վրա և թողնում ֆիզիկական ադապտերի լուծիչը իր տեղում, ուստի թե ով է հաղթում, կախված է միջերեսի մետրիկայից և հարցվող անունից։ Եթե ներքին պատասխանը գալիս է միայն այն ժամանակ, երբ ֆիզիկական ադապտերը անջատված է, դա է վերանորոգման ենթակա մեխանիզմը, ոչ թե դոմենի գրառումները։

Ընդունեք հայտնաբերման կանչով և մեկ կենդանի գործողությամբ

Օգտակար ընդունման թեստը կատարում է տեղորոշիչ հարցումը և ապա կատարում մեկ իրական նույնականացված գործողություն, օրինակ՝ բացում է գրացուցակով աջակցվող համօգտագործում կամ տոմս է հայցում։ Արեք դա VPN-ի անցումից առաջ և նորից հետո, նույն մեքենայի վրա, առանց միջանկյալ վերագործարկման։ Քեշավորված հավատարմագրերն ու արդեն բաց նստաշրջանները հաճույքով կստիպեն կոտրված ուղին առողջ երևալ, ուստի հաջող աշխատասեղանային մուտքը թեստը չէ։

Microsoft-ի DNS հաճախորդի վերաբերյալ առաջարկությունները նույն սահմանն են գծում ներքին անվանատարածքի լուծման և հանրային հարցումները վերև փոխանցելու միջև, և դա է այն դասավորությունը, որը պետք է պահպանել VPN ներդնելիս։

Եթե խափանումը միայն դանդաղ է, այլ ոչ ձախողված, դանդաղեցումը առանձին պահեք ախտորոշումից։ Հայտնաբերման ընթացքում ժամանակի սպառումը կարող է գալ անհասանելի կարգավորիչից, արգելափակված պորտից կամ ուշ պատասխանող լուծիչից, և դրանցից ոչ մեկը միայն սպասելով չի ապացուցվում։ Գրանցեք իրական հարցումը, դրա պատասխանը և կապի փորձը՝ նախքան լուծիչի պարամետրը փոխելը։