运维手册：分别接入两个 OpenVPN 客户

一台主机上放两个客户，听起来不过是再加一个服务器块和第二个端口。可一旦把客户真正拥有的东西全部列出来，它就成了另一个项目：监听器、隧道池、身份、信任文件、路由和吊销计划。漏掉其中一项，第二个客户就会悄悄继承第一个客户的一部分。为每个客户建一张卡片，并在第一个客户端连接之前填好。

为每个客户分配一张完整的资源卡片

把整套资源一起预留：公网端口、隧道子网、配置路径、日志去向、服务实例名和设备。把它们作为一个组来命名，才能避免那种经典错误：复制一份仍在运行的文件，而里面还留着第一个客户的地址池或接口。这些值只是示例，并非保留端口，所以要确认主机已经在用什么。服务能启动，并不等于客户已经配齐。

把卡片放在配置旁边，任何值变化时都更新它。与现实脱节的文档比没有文档更糟。

把信任材料留在每个客户内部

为每个客户使用独立的签发机构，边界就容易推理，签名密钥也能远离面向互联网的主机。共用根也可以，但共同的锚点并不会把两个服务变成一个成员域。决定每个监听器接受哪些证书链、授权哪些客户端身份，然后把两者都写下来。不要靠反复试错从链里剥掉证书，直到某个东西连上为止。

服务器自己的私钥应放在每个客户受保护的文件里，而不是放在随配置一起复制的模板目录中。

不仅隔离进程，也要隔离网络

两个端口上的两个进程仍然共享一台主机和一张路由表，除非你把它们分开。在相信设计之前，先确认到底是谁在监听。

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

监听检查能看出哪个进程占着每个公网端口，验证则能看出客户端证书是否链到预期的锚点。这两项输出都不能证明 A 的客户端到不了 B 的子网，所以要定义源与目的策略、返回路由，以及任何有意共享的服务。网络命名空间或容器能分隔路由上下文、减少意外混用，但它们并不是完整的租户边界。当威胁模型要求时，选择更强的隔离机制。

在移交之前把吊销送达

在吊销拥有交付路径之前，证书部署不算完成。把检查 CRL 的签发者和有效期窗口作为接入工作的一部分。

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

CRL 检查会报告列表何时签发、何时过期，服务状态则确认读取它的实例正在运行。即使没有新的吊销，也要按签发策略的节奏刷新列表，因为过期的 CRL 可能拒绝每一个客户端。要发布完整文件，而不是让读取方遇到写了一半的内容，并在部署前验证签名。记录谁负责签发、端点运维和退役，这样关停客户 A 不会扰动 B。

然后跑那对验收：被允许的客户端能到达自己的服务，而 A 的凭据会被 B 的监听器拒绝。这就是用测试表达出来的边界。