IPv6 隐私地址还是 RDP 允许列表：在权衡中做出选择

远程桌面访问正常运行了一个月，随后允许列表在没有任何可见原因的情况下不再匹配。主机没有移动，防火墙里也没有任何改动。Windows 会不断生成带有随机接口标识符的 IPv6 临时地址并将其弃用，因此服务器某天看到的源地址，可能是没有人写进规则里的那一个。关闭这一行为可以修正匹配，但同时会把主机变成一个长期有效的标识符。在接受后半部分之前，请权衡这些替代方案。

规则为什么不再匹配

RFC 4941 描述了临时地址：主机会创建带有随机标识符的附加地址并将其弃用，这使观察者无法把同一台主机跨多次访问关联起来。Windows 实现了这一行为，因此昨天的源地址不一定就是今天的。可预测的地址仍然存在于接口上；只是出站连接并不优先选用它。

这就是故障看起来时有时无、而非彻底失效的原因。地址创建后的一段时间里规则能够匹配，地址被弃用后就不再匹配，等有人重新编辑之后又开始匹配。按源地址分组的监控和以主机地址为键的授权检查，会按同一个周期失灵。一条刚编辑完能用、三周后却失败的规则，通常就是这个原因，而不是防火墙重新加载。

方案一：一个稳定地址，更少的隐私

常见的修复方式是关闭主机上的两个轮换机制：netsh interface ipv6 set privacy state=disabled store=persistent 和 netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent。如果你希望改动无需等待重启即可生效，可以加上 store=active，同时也要接受：你已经让这个标识符在不同网络之间变得可预测。

这种可预测性正是这些扩展机制想要避免的。一个会跟着主机从咖啡馆到办公室再到家里的地址，既是方便的过滤键，也是同样方便的追踪键，而后一种属性会比当初要求前一种属性的工单活得更久。

方案二：允许一个前缀或一个名称

允许 /64 而不是完整地址，可以保持轮换不变，也符合一个更弱但往往更诚实的说法：这台机器在我家的网络上。一旦该前缀里出现你不愿放行入内主机，它就不再够用；而在家庭宽带上，这个集合通常比人们以为的要小。通过动态 DNS 发布的名称更容易运维，因为记录会跟随主机，策略读起来是一个身份，而不是每增加一台设备就扩大的范围。

两种方案都需要服务器能够信任的解析器，以及一个不能轻易被伪造的名称，所以请把它们当作关于身份的策略决定，而不是对规则的外观改动。写下由哪个解析器回答那个名称，因为规则的可信程度不会超过它背后的记录。

方案三：让隧道来分配地址

如果连接经过你控制的 VPN，服务器就可以从自己的地址池中分配地址，允许列表引用的就是服务器选择的值，而不是客户端偏好的值。这对受管理的客户端很有效，对客户端能够覆盖的任何东西却很糟糕，所以要确认在你的部署中究竟是哪一方真正占上风。

把决定完全从地址上移开，交给客户端证书或经过认证的网关，才是能够扩展的方案，因为它不再依赖一个操作系统有权更改的值。

把追踪成本放在眼前来做选择

把四个方案对照实际需求写下来，并选择其中一个，而不是把它们组合起来。如果你终究要关闭隐私，就把它限制在需要的那台主机上，在规则旁边记录原因，并在平台支持的地方考虑 RFC 7217 的稳定隐私地址，因为它在不暴露硬件派生标识符的前提下保留了按前缀区分的标识符。当允许列表被替换时，请重新启用这些扩展。

把这项改动记录在它所支撑的规则旁边。没有这条备注，下一位管理员会看到一台关闭了隐私扩展、却没有任何说明的主机，并在一次清理中把它们重新打开。