在 Juju charm 变成你的 VPN 之前：身份、契约、端口

有人找到一个宣称能运行 VPN 的 charm，部署它，暴露应用，然后等待客户端连接。部署成功了，端口打开了，隧道却仍然不通，因为三个互不相关的承诺被混为一谈。charm 是一种带有特定契约的部署实现。把这些承诺拆开来看，缺口会在上线之前而不是之后暴露出来。

第一步：固定你正在阅读的产物

阅读候选 charm 自身的元数据：发布者、源码仓库、通道、修订版本、基础镜像和架构。然后确认谁维护工作负载内的 VPN 软件、谁负责提供它的安全更新，因为这往往是两个不同的主体。维护良好的 charm 里若有无人维护的上游，就是一个迟早会在糟糕的一周爆发的支持问题。

juju info CHARM_NAME 在 Juju 3.6 中报告通道、基础镜像和架构，文档也指出特定修订版本的查询不能与这些过滤条件组合使用。请单独查询修订版本，而不是构造一个命令会拒绝的组合。也要阅读基础镜像和架构，因为一个通道可能覆盖多个。

把审阅过的确切组合记录在部署旁边。这样，移动通道的刷新就是一次有前后对比的有意变更，而不是周一的意外。

第二步：把配置当作契约来读

确定 charm 扮演的角色：终止远程访问、加入现有 VPN，或者完全不同的其他事情。然后看它如何记录客户端注册、受信任的签发者、凭据轮换和吊销。这四件事决定你能否运营它，而生成的客户端文件是敏感输出，不是用来贴工单的文件。

遵循 charm 真正暴露的接口和操作。不要因为同款软件的另一个 charm 有注册操作，就以为这里也有。

问清楚协调对手工修改会做什么。如果 charm 在下次更新时覆盖配置文件，那么手工修复的保质期只有一次升级。向维护者询问这种行为记录在哪里，并把沉默当作未知。

第三步：把监听端口与转发路径分开

外层监听器是接受隧道的套接字。转发是隧道内部流量发生的事，返回路径则让响应能够回来。charm 可以交付第一件事，而把另外两件留给基础设施团队。

出口是第三块。如果隧道客户端要通过这台主机访问互联网，就必须有寻址或地址转换的安排，而它不是靠打开端口创造出来的。在第一个客户端到来之前，为这块指定负责人。

第四步：暴露是防火墙操作

在 Juju 3.6 中，暴露应用会调整云防火墙规则，默认允许来自任何源的流量进入工作负载已打开的端口。该命令的 endpoint 和 CIDR 选择器正是为了让这个默认值可以被收窄。

暴露不会创建 VPN 用户、不会校验他们的凭据，也不会安装转发策略。它也不能证明工作负载正在你预期的地址和传输上监听，所以暴露之后的测试比成功消息更重要。既要检查单元上正在监听的套接字，也要检查云规则。

第五步：用四项测试验收

获批部署之后，注册一个新客户端并确认预期的私有服务。然后吊销该身份，确认访问真的终止，而不只是下一次登录被拒绝。从不属于你控制的网络重复检查，再从办公室内部重复一次，因为这两条路径回答的是不同的问题。

最后做一次升级和重连，因为协调、凭据处理和服务重启正是在这里相互作用。如果文档无法说明其中某项操作归谁所有，就把它写成采用缺口，而不是用同一 charm 名背后的无人维护配方去填补。写下来的缺口是一个决定；悄悄填补的缺口是未来的故障。把它交给拥有服务决策的人，并附上你发现它的日期。