添加 RDP 允许规则并不会收窄你的 VPN 访问范围

这个计划听起来合理：保留现有的远程桌面允许规则，另外为那台唯一应获准访问的 VPN 客户端添加一条小规则。Windows 防火墙并不是这样工作的。规则不是按顺序排列、由最具体条目胜出的列表，而在宽规则旁边再加一条窄规则不会带来任何变化，因为宽规则仍然放行它原本就放行的所有来源。要收窄服务范围，必须编辑那条真正起作用的允许规则。

你添加的规则并不是关键的那条规则

Windows 防火墙会评估该计算机所适用的各策略存储中的所有入站规则，然后判断是否有某条允许规则匹配，以及是否有某条阻止规则将其覆盖。添加规则只是增加一条允许，并不会删除或限定已有的允许。

因此问题从来不是你添加了什么。而是在本地策略、域策略和配置文件默认值合并之后，有效策略里到底包含什么。只有一条本地规则的工作站容易推理；加入域的服务器则不然。

这也是为什么管理员可能做出一项看起来正确的更改，从错误的机器上测试，然后得出它生效了的结论。被排除的来源从未被测试过。只证明成功的测试，连这次更改目标的一半都证明不了。

弄清服务器看到的地址

在限定任何范围之前，先在 Windows 主机上观察一次被允许的会话，并记录服务器所报告的源地址。它并不总是客户端自以为拥有的那个地址。

如果 VPN 网关保留客户端地址，服务器看到的就是客户端的隧道地址，按地址限定范围才有意义。如果网关做地址转换，每个客户端到达时都是网关地址，限定到该地址就等于放行它背后的所有客户端。这时规则精确地指向了错误的对象。

这两种设计需要不同的答案。前者可以写成一条防火墙规则；后者必须在身份仍然存在的地方实施，也就是 VPN 本身，或服务前面那台经过认证的网关。

防火墙筛选器无法恢复网络地址转换所丢弃的身份，无论地址输入得多么仔细。

更改有效规则的归属

检查有效的入站策略，找出当前所有放行 RDP 流量的规则，包括显示名称从不提及 3389 端口的规则。按服务限定和按应用程序限定的规则也要算进去，某些 RDP 部署启用的 UDP 传输同样如此。

然后通过拥有这些规则的那个存储来编辑现有规则。对同时由域策略定义的规则做本地修改，可能会被合并、忽略或覆盖，在依赖它之前值得先弄清究竟会发生哪一种。

以下命令会找出活动规则、显示附着在其中一条上的地址筛选器，并预览范围更改：

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

这里的规则名称是审查结果中的占位符，预览标志的存在是为了让地址中的笔误不会把你锁在你正在编辑的服务器之外。

先阻止再允许是另一种模型

来自其他防火墙的习惯是先写一条宽泛的阻止，再在上面加一条窄允许。在 Windows 中，显式阻止通常优先于允许，因此这种顺序产生的是一个谁都到不了的服务，而不是为某个客户端开例外。结果看起来像 RDP 服务坏了。实际上却是优先级错误，解决办法是移除那条阻止，而不是再加一条允许。

保持活动配置文件上的默认入站阻止行为，转而收窄具体的允许规则。这样机器只剩一种可理解的状态，而不是两条相互矛盾的规则、其交互还取决于优先级细节。

用第二个来源来证明

从被允许的客户端测试，再从应当失败的来源测试。一次成功连接只能证明被允许的路径可用，对你刚刚做的排除毫无说明。

如果服务器启用了 IPv6，再重做测试，因为只针对 IPv4 的意图可能与一条无人查看的宽泛 IPv6 允许并存。

最后，把身份验证与可达性分开。网络级身份验证、账户权限和登录限制仍然决定谁能使用会话，防火墙只决定谁可以发问。以后移除设备时，应同时移除它的 VPN 注册和这项网络权限，否则你限定过的地址终有一天会属于别人。