SMB 防火墙规则中的 LocalSubnet 不会覆盖 VPN 客户端
LocalSubnet 允许规则覆盖服务器自身的子网，而不是被路由的 VPN 地址池。在扩大范围之前，先比较服务器实际看到的源地址。
办公室桌面能访问共享，VPN 用户却超时，而同一账号用手机热点却正常。差别很少出在共享权限上，通常出在到达文件服务器时的地址上。限定为 LocalSubnet 的规则只放行服务器自身已连接的子网，单独路由的 VPN 池并不属于其中之一。两种设计都能补上这个缺口，但留下的记录截然不同。
两种设计，一个症状
第一种设计把 VPN 池加入规则的远程地址条件。服务器随后看到每个客户端的隧道地址，因此日志可以区分不同的远程用户。第二种设计让 VPN 流量经过网关，在服务器看到之前转换成 LAN 地址。这恢复了连通性，同时也在同一步抹掉了这种区分。
这张表描述的是角色而不是地址，具体哪一行适用由你自己的前缀决定。请打印服务器的真实值，而不是照抄博客文章里的示例：
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength这张表只是决策参考，并不适用于所有部署。带有额外网卡、第二条站点链路或不同掩码的主机，其本地集合并不相同。
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
Microsoft 的 New-NetFirewallRule 参考记录了远程地址条件和 LocalSubnet 关键字。在断定该关键字代表所有私有地址之前，请先阅读它，因为它并不是。
比较服务器实际收到的内容
阅读生效中的规则，而不是某个人记忆中创建的规则。确认它已启用、应用于当前配置文件，并且其远程地址条件与服务器看到的源地址一致。只在 Domain 配置文件上启用的规则，在网络变化后网卡切换到 Public 时不会起任何作用。
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction第一条命令打印与文件共享规则绑定的地址筛选器，第二条显示哪些配置文件处于活动状态，以及不匹配的入站流量如何处理。还要查找阻止规则和集中管理的策略。阻止规则优先于允许规则，而禁用本地规则合并的策略会让新的本地例外失效。
这正是规则在控制台中看起来正确、却对流量毫无效果的情形。同时检查配置文件分配，因为接入过其他网络的笔记本电脑可能在无人触碰防火墙的情况下切换到 Public 配置文件。
先测试传输层，再测试登录
把可达性与身份验证分开。TCP 445 上的监听只能证明某个服务绑定了该端口，不能证明远程数据包能够到达它。反过来，完成的 TCP 连接也还不能说明 SMB 会话建立或共享权限。在修改规则之前，先从两端测试握手。
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailed第一条命令报告从你运行它的机器上 TCP 握手是否成功，第二条会补充解析后的地址和接口详情。分别从 VPN 客户端和办公室桌面运行，然后比较。Ping 对这两个问题都答不了，因为 SMB 开放时 ICMP 可能被阻止，或者在防火墙丢弃 445 时 ICMP 反而被允许。
如果只有从 VPN 发起时握手失败，源地址范围就是首要嫌疑。如果握手成功而共享仍然拒绝你，应当转向 SMB 会话和权限诊断，而不是修改防火墙规则。
当源 NAT 抹掉了区分
路径上存在地址转换时，服务器无法按地址区分单个 VPN 客户端。每个远程用户都以网关的身份到达。任何依赖区分他们的授权，都必须在身份仍然可见的地方执行，通常就是 VPN 集中器或进行认证的代理。防火墙规则可以放行流量，却无法恢复转换已经抹掉的区分。
一旦允许该网关地址，每个远程用户都会被记录在同一个地址下，规则等于把整个地址池授予任何能到达网关的人。如果需要按用户做决定，就要让原始地址保持可见，或者把决定移到仍然知道用户身份的一层。否则每个远程用户都会继承服务器所能看到的那个唯一地址的权限，事后审计记录也无法把他们区分开。这是设计决策，而不是防火墙的细节。
请有意识地在两种设计之间选择。服务器必须知道是谁连接时，就把规则限定在真实的 VPN 池上；只有服务器确实不需要该信息时，才接受经过转换的路径。把选定的源地址范围记在规则旁边，因为下一个排查这个问题的人会先看地址表。