Гасцявы ўваход SMB праз VPN: Windows па-ранейшаму патрабуе ідэнтычнасць
Працоўны тунель VPN не робіць ананімны ўваход SMB аўтэнтыфікаваным. Прачытайце палітыку кліента, пацвердзіце падзею 31017, затым выкарыстайце названы ўліковы запіс агульнага рэсурсу.
Падключэнне да офіснага 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. Калі абнаўленне прашыўкі дадае ўліковыя запісы карыстальнікаў, гэта больш танны доўгатэрміновы адказ.
Запішыце прыняты ўліковы запіс і значэнні палітыкі ў заяўку. Інакш наступны чалавек зноў запусціць тэст тунеля і атрымае тую ж адмову.