SMB համօգտագործումը ձախողվում է միայն VPN-ով. ստորագրությո՞ւն, թե՞ ենթացանցի բախում
LAN-ում աշխատող համօգտագործումը կարող է ձախողվել միայն թունելով։ Առանձնացրեք ստորագրության մերժումը, համընկնող ենթացանցը և հնացած SMB սեսիան։
Քարտեզագրված սկավառակը, որն աշխատում է գրասենյակում և տանը ժամանակավրջվում է, ինքնին գրեթե ոչ մի օգտակար տեղեկություն չի տալիս։ Թունելն ակնհայտորեն փոխանցում է փաթեթներ, այլապես ոչինչ չէր հասնի սերվերին։ Ձախողվել է երեք շերտերից մեկը՝ անունը լուծվել է սխալ հասցեի, հաճախորդը հրաժարվել է ստորագրել սեսիան, կամ հին սեսիան վերապրել է այն կապը, որը տանում էր այն։ Յուրաքանչյուրն ունի տարբեր վերանորոգում, և երեքից երկուսը հաճախորդի կողմում են։
Երեք խափանում կրում են նույն սխալը
Սկավառակի տառը չի ասում, թե որ շերտն է կոտրվել, և սխալի տեքստը սովորաբար բավական ընդհանուր է, որպեսզի համապատասխանի բոլոր երեքին։ Առանձնացրեք դրանք երկու արագ հարցով՝ սերվերը պատասխանո՞ւմ է իր IP հասցեով, և 445 պորտն ընդունո՞ւմ է կապ։
Այդ պատասխանները տալիս են որոշման աղյուսակ՝ ենթադրության փոխարեն։ Եթե IP-ն աշխատում է, իսկ անունը՝ ոչ, դա մատնանշում է անունների լուծումը։ Եթե երկուսն էլ աշխատում են, բայց մուտքը մերժվում է, դա մատնանշում է ստորագրությունը։ Եթե երկուսն էլ աշխատում են, բայց ֆայլի ընթերցումը կախվում է թունելի ընդհատումից հետո, դա մատնանշում է հնացած սեսիան։
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
Անցեք դրանց այդ հերթականությամբ, որովհետև սխալ հոսթին լուծվող անունը անիմաստ է դարձնում յուրաքանչյուր հետագա թեստ։
Լուծեք անունը, նախքան համօգտագործմանը դիպչելը
Եթե սերվերը պատասխանում է իր հասցեով, իսկ համօգտագործման անունը ժամանակավրջվում է, թունելն անում է իր գործը, և հաճախորդը սխալ տեղում է փնտրում։ Հեռավոր մուտքի դեպքում դրա մեծ մասը բացատրում են երկու պատճառ։
Առաջինը հասցեների համընկնումն է։ Երբ գրասենյակը օգտագործում է 192.168.70.0/24, իսկ տնային երթուղիչը տրամադրում է նույն տիրույթը, 192.168.70.20-ին լուծվող հոսթի անունը կարող է մատնանշել տեղական սարքի՝ թունելի հետևում գտնվող սերվերի փոխարեն։ Windows-ը կարող է այդ դեպքում հարցումն ուղարկել տեղայնորեն, մերժել երթուղին կամ լուծել այն տպիչի, որն ի զորու է ունենալ այդ հասցեն։ Վերանորոգումը մի կողմի վերահամարակալումն է, ոչ թե ևս մեկ երթուղի ավելացնելը։
Երկրորդը DNS-ի շրջանակն է։ Ներքին DNS սերվեր չունեցող կամ թունելով անհասանելի սերվեր ունեցող VPN ադապտերը կարճ անունները թողնում է հանրային լուծիչի։ Կարդացեք ադապտերի DNS գրառումները և ուղղակիորեն հարցրեք ներքին անունը, նախքան համօգտագործմանը դիպչելը։
> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15Եթե այդ հարցումը վերադարձնում է սպասված հասցեն, անունների լուծումը պարզված է, և խնդիրն ավելի վերև է կույտում։
Կարդացեք ստորագրման պահանջը երկու ծայրերում
Հասանելի սերվերը, որը մերժում է ամեն մուտք, քաղաքականության անհամապատասխանության նշան է, ոչ թե ցանցային խափանման։ Windows-ը կարող է պահանջել SMB ստորագրում հաճախորդի վրա, և սերվերը կամ NAS-ը, որը չի ստորագրում, չի կարող ավարտել սեսիան, որքան էլ թունելը առողջ լինի։
Կարող եք կարդալ հաճախորդի կարգավորումը՝ առանց քաղաքականության խմբագրում որոնելու։
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionՍերվերի կողմի համապատասխան արժեքը գտնվում է սերվերի SMB կազմաձևում, և երկուսը պետք է համընկնեն։ Մեկ հաղորդված դեպքում հաճախորդի մոտ պահանջը միացված էր տեղական քաղաքականությամբ, մինչդեռ սերվերը բոլորովին չէր ստորագրում։ Այն անջատելը և gpupdate /force գործարկելը անմիջապես վերականգնեց համօգտագործումը։ Սա ախտորոշիչ քայլ է՝ պատճառը հաստատելու համար, ոչ թե մշտական լուծում։
Նախընտրեք միացնել ստորագրումը երկու ծայրերում, որտեղ սերվերը դա աջակցում է։ Համօգտագործման աշխատանքի համար անվտանգության կարգավորումը փոխելը պետք է գրանցվի նախորդ արժեքի և պատճառի հետ, որպեսզի ոչ ոք ստիպված չլինի նորից բացահայտել այն հաջորդ աուդիտի ժամանակ։
Մաքրեք հնացած սեսիան, նախքան ժամաչափերը կարգավորելը
Համօգտագործումը, որը կախվում է միայն VPN-ի անկումից և վերամիացումից հետո, սովորաբար պահում է սեսիա, որը սերվերն արդեն դեն է նետել։ Սերվերը փակում է անգործ SMB սեսիաները Autodisconnect ժամաչափով LanmanServer\Parameters-ում, որն ըստ լռելյայնի 15 րոպե է, մինչդեռ հաճախորդն ունի իր SessTimeout-ը LanmanWorkstation\Parameters-ում։ Այդ արժեքներից ավելի երկար ընդհատումը յուրաքանչյուր ծայրին թողնում է սեսիայի մասին տարբեր պատկերացում։
Վերարտադրեք այն ֆիքսված հերթականությամբ, որպեսզի արդյունքը ինչ-որ բան նշանակի. միացրեք թունելը, բացեք համօգտագործումը, երկու րոպեով անջատեք թունելը, վերականգնեք այն, ապա փորձեք կարդալ ֆայլ։ Եթե միացումն ինքնուրույն վերականգնվում է, ժամաչափերին ձեռք չտաք։ Եթե այն կախված է մինչև վերամիացումը, վերամիացրեք համօգտագործումը թունելը բարձրացնելուց հետո՝ դրանից առաջ միացնելու փոխարեն, և ստուգեք, արդյոք միացման օգնականը կրկնում է փորձը։
Ժամանակային սահմանաչափերի բարձրացումը խելամիտ վերջին քայլ է անկայուն կապի համար, բայց այն բուժում է ախտանիշը։ Հաճախորդը, որն ավելի երկար է սպասում սեսիային, որը սերվերը մոռացել է, դեռ սպասում է։
Ավարտեք՝ կարդալով մեկ ֆայլ միացման միջով, ապա ևս մեկ անգամ անջատելով և վերականգնելով թունելը։ Այդ ընդունման թեստը միանգամից ընդգրկում է բոլոր երեք շերտերը, և դա միակ թեստն է, որը համապատասխանում է այն բանին, ինչ օգտատերն իրականում անում է։