SMB бөлісуі тек VPN арқылы істемейді: қолтаңба немесе ішкі желі қақтығысы?

Кеңседе жұмыс істеп, үйде уақыт шегінен шығатын салыстырылған диск өздігінен пайдалы ақпарат бермейді. Туннель пакеттерді анық тасымалдап тұр, әйтпесе серверге ештеңе жетпес еді. Сәтсіз болған нәрсе үш қабаттың бірінде: атау дұрыс емес мекенжайға шешілді, клиент сессияға қол қоюдан бас тартты, немесе ескі сессия оны алып жүрген қосылымнан ұзақ өмір сүрді. Әрқайсысының өз жөндеуі бар, ал үшеуінің екеуі клиент жағында.

Үш ақау бір қатені киеді

Диск әрпі қай қабат сынғанын айтпайды, ал қате мәтіні әдетте үшеуіне де сай келетіндей жалпы болады. Оларды екі жылдам сұрақпен бөліңіз: сервер өз IP мекенжайымен жауап бере ме, 445 порты қосылымды қабылдай ма?

Бұл жауаптар болжамның орнына шешім кестесін береді. IP жұмыс істеп, атау істемесе, бұл атау шешімін көрсетеді. Екеуі де жұмыс істеп, кіру қабылданбаса, бұл қолтаңбаны көрсетеді. Екеуі де жұмыс істеп, туннель үзілісінен кейін файл оқу ілініп қалса, бұл ескірген сессияны көрсетеді.

Оларды сол тәртіппен өңдеңіз, өйткені қате хостқа шешілген атау кейінгі әрбір тестті мағынасыз етеді.

Бөлісуге тиіспес бұрын атауды шешіңіз

Егер сервер өз мекенжайымен жауап беріп, бөлісу атауы уақыт шегінен шықса, туннель өз жұмысын істеп тұр, ал клиент дұрыс емес жерден іздейді. Қашықтан қатынаста бұның көбін екі себеп түсіндіреді.

Біріншісі — мекенжайлардың қабаттасуы. Кеңсе 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 сессияларын LanmanServer\Parameters астындағы Autodisconnect таймерімен жабады, ол әдепкіде 15 минут, ал клиенттің өз SessTimeout LanmanWorkstation\Parameters астында бар. Осы мәндерден ұзақ үзіліс әр ұшты сессия туралы басқа түсінікпен қалдырады.

Нәтиже мағыналы болуы үшін оны тұрақты ретпен қайталаңыз: туннельді қосыңыз, бөлісуді ашыңыз, туннельді екі минутқа үзіңіз, қалпына келтіріңіз, содан кейін файл оқуды көріңіз. Егер тіркеу өзі қалпына келсе, таймерлерді тыныш қалдырыңыз. Егер қайта тіркелмейінше ілінсе, туннель көтерілгеннен кейін бөлісуді қайта қосыңыз, ол пайда болмай тұрып тіркеудің орнына, және тіркеу көмекшісі қайталап көретінін тексеріңіз.

Уақыт шектерін көтеру тұрақсыз байланыс үшін орынды соңғы қадам, бірақ ол симптомды емдейді. Сервер ұмытып кеткен сессияны ұзағырақ күткен клиент әлі де күтеді.

Тіркеу арқылы бір файлды оқып, содан кейін туннельді тағы бір рет үзіп, қалпына келтіріп аяқтаңыз. Сол қабылдау тесті үш қабатты бірден қамтиды және пайдаланушының шын мәнінде жасайтынына сай келетін жалғыз тест.