VPN-ում խմբային քաղաքականությունը բացակայում է? Ստուգեք շրջանակը թունելից առաջ

Ինչ-որ բան, որ գործում էր գրասենյակի ցանցում, դադարում է գործել այն շաբաթ, երբ օգտատերը սկսում է աշխատել VPN-ով, և թունելն է մեղադրվում նախքան որևէ մեկը կբացի հաշվետվությունը։ Խմբային քաղաքականությունը որոշում է, թե որ կարգավորումներն են հասնում Windows-ի օգտատիրոջը և համակարգչին, նյութը վերցնում է տիրույթից և կատարում է հաճախորդի կողմի մշակումը, և այս երեք քայլերը ձախողվում են երեք տարբեր ձևերով։ Թունելը փոխում է միայն այն, թե ինչ ուղի ունի հաճախորդը։ Ստուգումները հերթով անցնելը թույլ չի տալիս, որ ֆայլի թույլտվությունների խնդիրը հետապնդվի որպես երթուղավորման խնդիր։

Սկսեք կարգավորումից, ոչ թունելից

Գրեք մեկ սպասվող GPO և դրա մեջ մեկ կոնկրետ կարգավորում, ապա որոշեք՝ այդ կարգավորումը օգտատիրոջ կոնֆիգուրացիայի մեջ է, թե համակարգչի կոնֆիգուրացիայի։ Սա ենթադրում է լիազորված Windows հաճախորդ, որը միացված է տիրույթին հաստատված VPN-ում, և ոչ թե չկառավարվող կամ միայն ամպային սարք, որը դարձվում է տիրույթի անդամ։ Շրջանակի պատասխանը որոշում է, թե ով կարող է կարդալ արդյունքը և արդյոք անհրաժեշտ է իրավունքների բարձրացում, ուստի դա որոշեք նախքան որևէ բան գործարկելը։

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

Կարդացեք հաշվետվությունը այն հաշվով, որին պատկանում է կարգավորումը

Տուժած օգտատիրոջ սեփական նստաշրջանում գործարկեք whoami /user, ապա gpresult /scope user /r։ Այն հաշիվը, որը նույնականացրել է VPN-ը, ինքնաբերաբար այն Windows հաշիվը չէ, որի քաղաքականությունը կարդում եք, և ադմինիստրատորի հաշվից արված ստուգումը պատասխանում է մեկ այլ հարցի։ Պահեք ելակետային վիճակը նոր ֆայլի անունով, օրինակ՝ %TEMP%\vpn-policy-user-before.html։ gpresult-ի հղումը նկարագրում է շրջանակի և ելքի անջատիչները, և արժե իմանալ, որ հաշվետվություն ստեղծելը ոչինչ չի թարմացնում։

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

Հայտնաբերումը հասանելիություն չէ․ նախ SRV գրառումները, ապա SMB

Հաստատված VPN-ը միացված վիճակում հաստատեք, որ հաճախորդը տիրույթի կարգավորիչները լուծում է նախատեսված DNS-ուղով․ բեռնվող հանրային կայքը ոչինչ չի ասում կարգավորիչների հայտնաբերման մասին։ corp.example օրինակելի տիրույթի համար nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example պատասխանում է այն հարցին, որն իսկապես ունեք։ Վերադարձված ծառայության գրառումը միայն հայտնաբերման ապացույց է, քանի որ ընտրված կարգավորիչի հասցեն դեռ պետք է հասանելի լինի պահանջվող նույնականացմամբ և թույլատրված գրացուցակի ծառայություններով։ Քաղաքականության նյութը հետո գալիս է SYSVOL-ից, ինչը SMB ընթերցում է հենց այդ կարգավորիչից և ոչ ICMP թեստ։

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

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

Մեկ թարմացում, երկու հաշվետվություն, մեկ համեմատություն

Երբ ուղին ապացուցված է, պահանջեք համապատասխան թարմացումը gpupdate /target:user-ով և կարդացեք արդյունքը՝ այն ենթադրելու փոխարեն։ Լռելյայն թարմացումը կիրառում է փոփոխված քաղաքականությունը, մինչդեռ /force պահանջում է կրկնակի կիրառում․ դրանցից ոչ մեկը չի վերանորոգում DNS-ը, ֆայլի թույլտվությունները կամ զտումը։ Որոշ ընդլայնումներ ավարտվում են միայն ավելի ուշ մուտքի կամ առաջին պլանի այլ իրադարձության ժամանակ, ուստի մեկ գործարկումը դատավճիռ չէ։ Հեռավոր օգտատիրոջ նստաշրջանին դուրսգրման կամ վերագործարկման անջատիչներ ավելացնելը որպես սովորական ախտորոշում՝ դեն է նետում այն, ինչ նա բաց էր պահել։

Ստեղծեք երկրորդ հաշվետվություն այլ ֆայլի անունով և համեմատեք մշակման ժամանակը, սպասվող GPO-ն, դրա կիրառված կամ մերժված կարգավիճակը և հենց կարգավորումը։ Նախորդ հաջող նստաշրջանի հաշվետվությունը ոչինչ չի ապացուցում այս թարմացման մասին։ Զտիչով դուրս մնացած քաղաքականությունը մատնանշում է կիրառելիությունը, ոչ թե փոխադրումը, ինչը փոխում է, թե ումն է հաջորդ քայլը։

Ձախողումը կապեք մեկ գործունեության հետ

Իրադարձությունների դիտիչում սկսեք համակարգի մատյանի խմբային քաղաքականության նախազգուշացումից կամ սխալից, ապա անցեք Ծրագրերի և ծառայությունների մատյանների տակ գտնվող GroupPolicy գործառնական մատյանին։ Զտեք այդ գործառնական մատյանը հենց նոր գործարկված թարմացման գործունեության նույնացուցիչով, քանի որ նոր թարմացումը ստանում է նոր նույնացուցիչ, և այն երեկվա իրադարձությունների հետ խառնելը տալիս է ինքնավստահ և սխալ եզրակացություն։ Գրանցեք ժամը, օգտատիրոջ կամ համակարգչի համատեքստը, ընտրված կարգավորիչը, GPO-ն, սխալի կոդը և ձախողված կախվածությունը։

Այդ գրառումն է, որի վրա կարող է գործել ցանցի կամ գրացուցակի սեփականատերը։ VPN-ին միացած լինելը և gpupdate-ը մի քանի անգամ գործարկելը ապացույց չեն, և դրանցից ոչ մեկը չի դիմանում հանձնմանը։

HTML հաշվետվությունները պահեք գաղտնի, քանի որ դրանք բացահայտում են ներքին անուններ, խմբային անդամակցություն և անվտանգության կոնֆիգուրացիա։ Կարգավորումը հաստատվելուց հետո հեռացրեք ավելացված ժամանակավոր թույլտվությունները՝ դրանք տեղում թողնելու փոխարեն։