为什么把 OpenVPN 服务器配置复制到分支会失败

把可用的服务器配置复制一份、改掉几个地址，再把它叫作分支配置，通常也能连上。这是最糟的结果，因为分支随后以错误的角色运行，暴露出本不该离开集线器的材料，还留下一条没人记得建立过的路由关联。这个连接同时掩盖了三个问题，而且隧道在任何人检查之前就已经起来了。

把分支当作拥有自身身份和网络角色的对等方，才是让配置正确的做法。修法不是做一份更好的副本，本页其余部分讲的是一个客户端究竟应该持有什么。

两个看起来像同一份文件的角色

在 TLS 模式下，两侧的职责互补。一侧监听，持有服务器证书与私钥，并决定哪些客户端可以连接。另一侧发起连接，验证监听方，并出示自己的身份。

服务器文件里有些指令在客户端上毫无意义：用于监听的绑定地址与端口、用于分配的地址池，通常还有一份推送列表，用来下发客户端应当收到的设置。把这些复制到分支，会造出一个既想当监听方又想当客户端的设备。

最要紧的是私钥。客户端绝不能携带服务器的私钥，也不需要 CA 的签名密钥。CA 证书是公开的信任材料；签名密钥应当留在签发证书的地方。

分支配置必须包含什么

分支配置需要远端端点与传输方式、受信任的服务器身份、分支自己的证书与私钥，以及分支真正需要的路由和 DNS 设置。除此之外都不是必需的。

每个站点都要有独立的分支身份。两个分支共用一个证书，意味着吊销其中一个就会让另一个失效，而集线器的日志也无法区分它们。按站点分配身份，审计轨迹和吊销流程才能同时成立。

小心设备厂商的工作流。pfSense 的 Client Export 包只为符合条件的 Remote Access 场景生成配置，它的服务器列表也只包含以 Remote Access 模式配置的服务器。其他模式的站点到站点服务器不会出现，而这种缺席本身就是信息，不是去复制服务器机密的邀请。

如果设备不导出你需要的配置，就使用它文档化的站点到站点客户端工作流，或依据已安装版本所支持的示例自行构建。只有当计划是恢复一台服务器时，才把服务器备份导出到分支，而这里并不是。备份同样携带集线器的私有材料，所以把它搬到分支是密钥处置决定，不是文件传输。把它留在集线器上，并在签发证书的地方生成客户端身份。

对等方与网段的关联是另一件事

分支客户端连接成功，仍然无法为其 LAN 转发流量，直到集线器知道这个对等方拥有那个前缀。这条关联存在于集线器上，以客户端身份为键，并且与分支自己通往远端网络的路由是两回事。没有它，分支的主机在隧道的统计里看起来可达，实际却不可达。确认关联是否生效，要看集线器的日志。

在集线器的操作系统里加一条路由，并不等于告诉 OpenVPN 哪个客户端拥有该前缀。没有按客户端建立的关联，数据包到达隧道接口后会被丢弃，因为没有对等方认领这个目的地址。

在分支这一侧，对应的需求是一条通往应达网段的路由，外加一台知道如何把流量送回分支的 LAN 路由器。服务器侧的所有权与客户端侧的目的路由是两个不同的对象，而一条能工作的隧道只证明第一跳。两样都要写进分支的交接记录，因为下一位工程师只会找到其中一样。

证明分支就是你以为的那个对等方

先验证身份，再验证流量。集线器日志应显示分支证书的通用名，客户端拿到的地址应与你要用的地址池或固定分配一致。如果日志显示的是别的名字，这份配置携带的就是别人的身份。

然后从分支主机向集线器侧的资源发一个请求，确认它以预期的源地址成功，以此验证关联。再测一个分支不该到达的目的地，确认它确实失败，因为一条碰巧能通的宽松路由并不等于正确的策略。

最后吊销分支身份，确认连接失败，而集线器自身证书与其他站点仍然正常。如果吊销把集线器弄坏了，说明角色与身份在某个地方被共享了，这个发现值得带回设计层面。

一个完成的分支，应当有书面身份、仅限客户端的配置、集线器上的对等方与网段关联，以及经过测试的返回路径。把服务器文件里的文字颠倒过来，一样都给不了你。