AD կայքի քարտեզագրում ընդդեմ VPN հաճախորդների համար տիրույթի կարգավորիչի ամրագրման

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

Ինչ է իրականում փոխում յուրաքանչյուր մոտեցում

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

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

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

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

Որտեղ է հաղթում ենթացանցի քարտեզագրումը

Լողավազանի քարտեզագրումը նկարագրում է ցանցային դիրքը մեկ անգամ, DC Locator օգտագործող յուրաքանչյուր հաճախորդի համար։ Երբ լողավազանը մեկ /24-ից աճում է երեքի, մոդելը փոխվում է երկու կամ երեք օբյեկտում՝ հավելվածների ցանկի փոխարեն։ Դա է ամբողջ առավելությունը, և այն մեծ է, երբ հաճախորդների թիվը ձեր վերահսկողության տակ չէ։

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

Երկրորդ սահմանափակումը․ կայքերի մոդելը նախապատվություն և տոպոլոգիայի հայտարարություն է։ Այն կարգավորիչին հասանելի չի դարձնում և օգտատիրոջը ոչինչ չի տալիս։ Հասանելիությունը տալիս են երթուղիները և հրապատի քաղաքականությունը․ թույլտվությունը՝ հաշվի քաղաքականությունը։

Որտեղ է հաղթում ամրագրումը

Ամրագրումը ճիշտ պատասխանն է, երբ հայտնաբերումը չի կարող աշխատել․ հին հավելված, որը կարգավորիչը լուծում է անունով, որը չեք կարող փոխել, զտիչ, որը թույլ է տալիս ուղիղ մեկ կարգավորիչի հասցե, կամ սերվերների ֆիքսված հավաքածու, որտեղ կարգավորիչը հավելվածի նախագծի մասն է։ Այդ դեպքերում ամրագրումը իրական սահմանափակման փաստաթղթավորում է, ոչ թե կարճ ճանապարհ։

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

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

Ընտրեք երեք պայմանով

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

Գրացուցակին տեղյակ հավելվածներ գումարած աղբյուրը պահպանող երթուղավորում գումարած փոփոխվող լողավազան․ քարտեզագրեք ենթացանցը։ Հավելված, որը չի կարող հայտնաբերել, կամ զտիչ, որը թույլ է տալիս մեկ հասցե․ ամրագրեք այն և գրեք ինչու։ Մնացած ամեն ինչ տոպոլոգիան ուղղելու գործ է, ոչ թե ևս մեկ վերագրանցում ավելացնելու։

Ստուգեք VPN հաճախորդից և առանձին պահեք պայմանագրերը

Փորձարկեք իրական հեռավոր ուղուց, ոչ թե LAN աշխատանքային կայանից, որն արդեն կայքում է։ Միայն հաճախորդի սեփական տեսքն է կարևոր․

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

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

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