稳定的 OpenVPN 地址应跟随身份，而不是源 IP

那些写着“这台笔记本拿到 10.90.0.10”的地址方案，其实是在陈述身份：哪一台通过认证的设备可以持有这个地址。那台设备当前的公网 IP 几乎与此无关，因为 NAT 和漫游会改变它，却不会改变用户是谁。把方案建立在源地址上，得到的规则在第一个酒店网络里就会失效。把方案建立在已认证的身份上，得到的方案能经得起出差。

先从服务器能够验证的东西出发，再决定这个地址是做什么用的。

先选身份密钥，再选地址

为每台设备单独签发客户端证书，能给服务器一枚稳定、可验证的密钥来对应每位成员，这是静态分配最干净的基础。采用按用户认证的部署可以改用用户名作密钥，只要配置的选取依据同一个字段。混用两种模型会得到这样的分配：一部分匹配某个客户端的证书，另一部分匹配另一个客户端的用户名，而没有人能预料哪一个生效。在写下第一条预留之前，先决定方案使用哪一枚密钥。

启用 duplicate-cn 时，多个同时存在的会话可以呈现同一个通用名，因此单一固定地址无法把它们逐一区分开。这是身份模型自身的性质，不是更好的地址方案所能修复的。

把预留地址放在动态范围之外

在 10.90.0.0/24 这类子网拓扑的网络里，把低位地址留给有名有姓的成员，把动态池放进一段不重叠的范围。固定成员的分配，在服务器为该身份选中的文件里长这样：ifconfig-push 10.90.0.10 255.255.255.0。第二个参数在 net30 下含义不同，所以这个例子并非拓扑中立。复制之前先读清楚拓扑。

地址池的持久化会记录最近的租约，并且倾向于把同一个地址发回去，这只是一种便利，不是预留。不要让持久化文件成为归属记录，因为它随连接历史变化，而不随策略变化。

分配优先级决定谁说了算

手册记载了一个顺序：在 client-connect 期间生成的显式分配可以先于 client-config-dir 条目生效，而后者又先于普通的地址池分配。这个顺序解释了大多数“固定地址没生效”的报告。它同时意味着，一个按会话写入配置的动态分配器，可以悄无声息地覆盖你以为是权威的静态文件。

只让一层负责分配，其余各层保持只读。两层都声称自己说了算，产出的分配就会取决于时序。

动态分配器需要同一套模型

按会话下发地址的 client-connect 集成是一个小型分配器，带着分配器常见的那些问题。它必须验证请求方的身份、原子地预留地址、只输出受支持的每连接指令，并在断开或失败时释放预留。并发请求需要锁或数据库约束，而不是先读后写。没有清理，地址池会一直泄漏地址，直到重启。

把分配器的状态放在下一位运维人员读得到的地方，并且记录从身份到地址的决策，而不只是地址。

判断这个地址属于策略还是便利

如果某条防火墙规则或路由允许来自某个隧道地址的流量，那么这个地址就参与了访问策略，一次重新分配会连带继承那项许可。把身份、地址与防火墙的生命周期协调起来，或者把规则绑定到无法被重新分配的东西上。稳定的地址编制让配置更易读；它并不取代认证。

把方案写成一份清单，每一项都有负责人，然后在设备退役时复查它。没被用掉的预留，恰恰是会被误用的那一个。