SMB հյուրի մուտք VPN-ով՝ Windows-ը դեռ ինքնություն է պահանջում

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

Ինչու թունելը չի կարող փոխարինել SMB ինքնությանը

Սերվերի հետ ենթացանց կիսելը երբեք չի նշանակել դրա ֆայլերը կարդալու թույլտվություն՝ այն միայն վերացնում է երթուղավորման խնդիրը։ Windows-ը գրանցում է 31017 իրադարձությունը, երբ իր հաճախորդը արգելափակում է անապահով հյուրի մուտքը, և դա որոշում է, որը կայացվում է ձեր մեքենայում, ոչ թե սերվերում։ Թունելը հավատարմորեն փոխանցում է SMB փաթեթները, մինչ հյուրի սեսիան մերժվում է։ Ահա թե ինչու նույնական տնային ցանցերում մի նոութբուք աշխատում է, իսկ մյուսը՝ ոչ։

Իրադարձությունը դիտարկեք որպես քաղաքականության ապացույց, ոչ որպես ցանցի խափանում։ Ուղղումը ինքնության կամ սարքի մեջ է։

Կարդացեք հաճախորդի քաղաքականությունը և մերժման իրադարձությունը

Երկու ելք արագ լուծում են հարցը՝ գործող հաճախորդի կոնֆիգուրացիան և վերջին մերժման իրադարձությունները։

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017

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

Օգտագործեք անվանված հաշիվ և պահպանեք ստորագրությունը

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

net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnection

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

Երբ սարքը ճանաչում է միայն հյուրին

Որոշ սպառողական NAS տուփեր համօգտագործումներ են առաջարկում առանց հաշվի գաղափարի, ինչը թողնում է երկու ազնիվ տարբերակ՝ մեկուսացնել սարքը կամ փոխարինել այն։ Տեղադրեք այն հատվածում, որտեղից զգայուն որևէ բանի ուղի չկա, և թույլ չտաք, որ հարմարության բացառությունը դառնա ամբողջ հաճախորդի լռելյայնը։ Պահուստային պատճեններ կամ հավատարմագրեր պարունակող հյուրի համօգտագործումը տվյալների բացահայտման խնդիր է, ոչ թե Windows-ի անհարմարություն։ Եթե որոնվածի թարմացումը ավելացնում է օգտվողի հաշիվներ, դա ավելի էժան երկարաժամկետ պատասխանն է։

Գրանցեք ընդունված հաշիվը և քաղաքականության արժեքները տոմսում։ Հակառակ դեպքում հաջորդ մարդը նորից կկատարի թունելի փորձարկումը և կհասնի նույն մերժմանը։