pfSense 中的静态隧道地址：偏好还是保留？

两种设计在纸面上看起来相似，但当某条规则依赖它们时，行为却截然不同。一种把地址填进客户端覆盖，并把该地址当作身份来信任。另一种彻底关闭动态准入，因此端点要么获得唯一分配，要么根本无法连接。只有第二种才把地址变成可以为之辩护的策略输入，而在写下第一条防火墙规则之前，这个差别值得弄清楚。

覆盖地址究竟承诺了什么

客户端专属覆盖携带逐客户端的选项，其中包含一个首选隧道地址。Netgate 把该地址描述为偏好而非保留，这意味着动态地址池不会把这个地址让给其他任何人。

这通常没问题。冲突很少见，客户端一般能得到它请求的地址，这对便利足够了，对授权还不够。便利和授权是不同的要求，而在一次冲突中只有其中一个能幸存。

在子网拓扑下，该字段接收客户端地址以及服务器网络的掩码，因此 10.90.0.0/24 隧道内的地址要写成 10.90.0.10/24。

这些都不能保留号段。覆盖未匹配上的客户端，或者重复的会话，可能落到地址池中的别处，而基于该地址的规则描述的便是一个并不在那里的人。

用限定范围的默认项关闭动态路径

另一种做法是纯静态服务器：每个被放行的端点都有自己的身份和自己的唯一地址，其他任何东西都进不来。

实现它意味着添加一条 DEFAULT 覆盖，只限定在那台服务器上，并启用连接阻断。没有匹配覆盖的客户端便无法退回普通动态准入。正是这一行把偏好变成了封闭集合。

范围很重要。把默认覆盖应用到设备上的每个 VPN 实例，会锁死无关的隧道，而这种故障看起来像服务坏掉，而不是策略决定。要把它绑定到你正在改变准入模型的那一台服务器上。然后在变更记录里注明范围，因为下一个人不会记得它属于哪条隧道。

之后审计整个允许集合。默认阻断并不能修复一条没有被分配地址的具名覆盖，那个端点只会连接失败，而且没有明显线索说明原因。

匹配服务器真正使用的身份

覆盖总要匹配某个东西。在按证书通用名匹配的服务器上，覆盖名必须是那个通用名，而不是此人的显示名。要从证书里复制，而不是从账户列表里抄。

若服务器被配置为用用户名作为通用名，它匹配的就是完全不同的键，而按证书命名的覆盖永远不会生效。要读设置，而不是从账户列表显示的内容去推断。

保留部署所需的额外认证因素。封闭地址模型改变的是谁可以连接、以及拿到哪个地址；它并不替代证书检查或第二因素。

映射可靠之后再写访问规则

一旦身份到地址的映射封闭起来，规则就可以引用地址，而不必假装地址是人。把一个用户所有端点归组的别名可以访问某个特定服务，而另一个别名访问别的东西。别名成为可评审的对象，地址则成为它内部的实现细节。

让目标和端口保持明确。允许整个隧道池访问整个本地网络，正是这次练习要替换掉的设计。

按真实求值顺序阅读浮动规则、组规则和接口规则，因为先前的宽泛放行会抵消后来的狭窄放行。关闭客户端之间的内部转发，可以把对等流量留在评审这些规则的边界上。只存在于纸面上的规则不是执行。

测试负面情形

演练四个全新连接：一个具名端点、一个完全没有覆盖的端点、一个应当可达的服务，以及一个不应当可达的服务。未列出的端点才是关键情形，因为设计存在的目的就是拦住它。如果它连上了，默认阻断就没有起作用。

单独检查 IPv6，因为 IPv4 地址策略对第二套协议栈什么也没说。然后确认应用仍然在授权用户，因为隧道地址是网络事实，而不是谁坐在键盘前的证明。两项检查都该写进验收记录。

最后，规划迁移。新的覆盖和狭窄规则不会追溯改变已经建立的会话，因此现有状态必须过期或被有意清除。