VPN 上的 SMB 来宾登录：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 的小毛病。如果固件更新能加上用户账户，那才是更便宜的长期答案。

把采用的账户和策略取值记进工单。否则下一个人还会重跑隧道测试，撞上同样的拒绝。