从 Access Server 到 Community OpenVPN：哪些部分必须重做

Access Server 与 Community OpenVPN 只共享同一套协议，其余几乎没有任何一处相同。握手、加密协商和隧道数据面彼此兼容，所以客户端往往不改配置就能连上两者。真正的差别在于配置归谁所有：一个产品附带会编写并强制执行策略的管理层，另一个只给你一个配置文件和一组钩子，然后等你自己决定。

这个差别就是迁移方案。旧产品替你做的每一个决定，都必须在新部署的某处变成明确的决定。

两套部署不再可互换的地方

在 Access Server 里，网页面板拥有用户、群组、按用户的权限、证书签发以及用户下载的配置文件包。 底层的守护进程由这一层配置，所以运行中的服务是很少有人手工编辑的存储状态的产物。在 Community OpenVPN 里，配置文件本身就是状态：它指定监听器、证书颁发机构、认证钩子和每一个下发的选项，没有任何东西替你重写它。同一套 TLS 机制因此处在两种截然不同的归属模式之下。

一张简短的对照表能把差距说清楚。用户和群组只存在于旧数据库里，除非你重新建。配置文件包变成配置文件加上你自己分发的证书。按用户的权限变成 client-config-dir 里的指令。管理面板变成你为签发证书和编辑文件而选择的那个流程。

在碰服务器之前先把这张表写下来。你填不出的每一行，都是一个你即将丢掉的特性，而悄无声息地丢，正是迁移在两周后变成故障的方式。

身份不会随证书文件一起搬过去

旧机构签发的证书可能在新服务里被正确解析，却仍然是错误的身份，因为旧产品把它们和账户状态绑在一起，而新服务看不到那部分状态。先决定新部署是只靠证书认证、靠能连到 PAM 或 RADIUS 的插件认证，还是两者结合，然后确认每种选择都保住了你需要的属性。没有按用户区分的共享证书，等于持有它的所有人共用一个凭据。吊销也必须从第一天起就能用，在 Community OpenVPN 里这意味着一个由 crl-verify 引用的 CRL 文件，外加一个负责重新生成它的流程。

把注册安排在切换之前，而不是之后。新证书、经过测试的吊销路径、以及停用某一个人的书面办法，都是前置条件，不是后续工作。如果多因素认证来自旧产品的集成，请明确写出替代方案，因为没装的插件会在最糟的时刻以拒绝服务的方式失败。

路由和域名解析跟着写配置的人走

路由、DNS 设置和全隧道行为在两种产品里都是下发选项，但只有一方替你计算。在 Community OpenVPN 里，push 指令要自己写，redirect-gateway 放在服务端还是客户端要自己定，主机上有没有转发和 NAT 也要自己确认。握手成功并不能说明转发、地址转换或客户端真正拿到的路由。

按客户端的行为需要 client-config-dir，以及在目录里以客户端证书 common name 命名的文件；站点到站点的对端则需要为它背后的前缀写 iroute。名字写错，选项会被静默忽略，而不报错。先用一个非生产客户端在它自己的地址池里试，然后读它被分配的地址、拿到的路由和最终的解析器设置。

给切换排好顺序，让旧服务能回来

让新监听器跑在不同的端口或地址上，在证明替代品可用期间让旧的一直提供服务。两个守护进程抢同一个套接字，不叫回滚方案。

一次只搬一个群组，连同它自己的证书、地址池和路由，并且演练回退路径，而不是在事故当中才发现它。只有先停掉新服务才生效的回滚仍然是回滚，但必须在没有着火的时候测过。

最后，把没有直接对应物的特性列出来，逐条用文字定下它们的去留：自助下载配置、按用户的权限开关、管理面板本身、实时连接报表。用一套有文档的手工流程替代它们，是站得住脚的答案；把那行留空则不是。

当从未见过旧门户的人能够注册、连接、到达预定的内部地址并被干净地吊销时，工作才算完成。在那之前的一切都只是准备。