面向单个云服务的原生 TLS、SSH 转发或 VPN

问题很少是要不要在兩台云主机之间加密什么，而是你在加密哪个接口、谁校验谁的身份。我从服务而不是网络图开始这类讨论，因为服务已经知道自己需要什么。三种边界覆盖大多数情况：应用自身的 TLS、经 SSH 转发的一个 TCP 端口，以及为每个参与者分配地址的路由叠加层。它们不按强度排序，而按覆盖问题的多少排序。

从服务开始，而不是从网络开始

从进程向外走。它说什么协议、客户端会校验哪个名字、谁被允许打开连接？这三个答案比任何对比表都更快地排除选项，而服务自身的配置通常几分钟内就能回答。

拿一个已经在 8443 端口提供 HTTPS、证书用于 api.internal.example 的小型内部 API。主机上的 ss -ltnp 显示它绑定到什么，而 openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example 显示证书对客户端实际使用的名字是否有效。两者都健康时，服务能保护自己的流，剩下的只是可达性。这比搭建网络小得多。

第 1 步：服务能保护自己吗？

合适时就选它，而它比团队以为的更常合适。服务的加密覆盖客户端与服务器之间的整条路径，包括中间每一跳，绕开中段的隧道无法改善这一点。显式设置期望的名字和信任，而不是依赖客户端默认存储里恰好有什么。

加密与可达性仍是两项独立控制，把它们合并正是这个选项出错的地方。无限制公网监听上的 TLS 服务仍然接受任何人的连接尝试，因此监听器和网络规则必须独立于载荷已受保护这一事实来划定。然后检查依赖，因为 TLS 之上的 API 并不说明发现端点、管理端口或旁边的大批量传输通道。每一项都需要自己的答案，而一个未受保护的同类就足以让整个边界成为空话。

第 2 步：一个 TCP 端口就是全部需求吗？

当需求确实只是一个 TCP 端口时，转发就是能用的最小方案。SSH 本地转发通过一条已存在的认证连接承载该端口。

形式是 ssh -N -L 8443:127.0.0.1:8443 [email protected]，关键细节是目标地址：127.0.0.1 在远端解析，因此到服务的连接从堡垒机而不是你的笔记本打开。把本地监听器窄绑定为 -L 127.0.0.1:8443:...，以免误把服务发布到你自己的局域网。服务器侧要限制账户可以转发什么，而不是相信客户端会守规矩。PermitOpen、AllowTcpForwarding local 和默认的 GatewayPorts no 是把通用中继变成特定通道的三项设置。

契约在两个方向上都窄。SSH 保护它自己的通道，而从堡垒机到另一个应用的下一跳需要自己的保护。只监听堡垒机 loopback 的服务与通过另一网络到达的服务暴露面完全不同，转发不会改变这一点。保留应用自身的认证和 TLS 检查，而不是把隧道当作它们的替代。

这对一条连接、一个所有者很合适。规模变大后它就成了系统：本地端口冲突、监管、密钥轮换，以及重启后谁来重启转发。

第 3 步：路由才是真正的需求吗？

那份清单是最小方案的真实成本，也是团队最终用受管方案替换几个被遗忘的后台命令的原因。替换并不自动等于 VPN。如果需求仍是一个 TCP 端口，带文档化所有者的受监管转发比叠加层更便宜，而且以你能看见的方式失败。先衡量运营归属，再衡量优雅。

当路由就是需求时，路由才是正确答案。多个应用需要普通 IP 连通性、TCP 转发承载不了的协议，或在主机之间迁移的服务，都指向同一方向。

叠加层给参与者地址和路由，然后真正的工作才开始：不重叠的网段、路由归属、DNS、注册、撤销，以及对端消失时怎么办。这些都不会随地址自动到来。被接纳进叠加层的对端也不会自动获得目标上每项操作的授权，所以服务级认证仍然保留。

之后你拥有什么

留下的记录里应有两件事。第一是客户端应当校验的身份，因为一旦为了让某样东西跑通而放宽名字检查，这些边界都会悄悄退化。第二是移除步骤：访问结束时哪把密钥、哪条规则或哪条路由消失，以及由谁执行。

这段走查在开始的地方结束，也就是服务。选择覆盖实际流量、并校验你真正想校验的对端的边界，然后写下访问如何更新、监控和移除。OpenSSH 参考是在承诺窄契约之前确认转发选项的地方。如果你无法用一句话描述移除步骤，边界就比问题更大。